You're running `clientSrc $$ serverSink` in a separate thread. What
it's doing is blocking for any kind of input from clientSrc before it
can continue. That thread knows nothing about the rest of the program,
including that serverSink is closed. This is inherent to the network
functions involved here.
It seems like this is a perfect time to pull out killThread, as
Alexander mentioned. It's a way to send a signal to a blocked thread,
which is what you have here. All of the conduit libraries have been
designed from the ground up to work correctly with asynchronous
exceptions, and all resources will be freed correctly. Is there a
specific reason why this seems like the wrong approach here?
Michael
On Sat, Mar 10, 2012 at 11:12 PM, grant
The problem is, how would I then go about creating a proxy like tcpmon?
I was going to replace this code 'clientSrc $$ serverSink' with this 'clientSrc $$ (sinkFork (sinkFile "randomname") serverSink' and the same for the 'serverSrc $$ clientSink' part.
However, since the 'clientSrc $$ serverSink' part will be suspended until the process has ended, I would be holding on to open resources for the whole time.
Is there a better way to create this proxy?
Thanks, Grant
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe