quoth Evan Laforge
Oh I see, because the subprocess inherits the socket connection. That makes sense, though it's tricky. Tricky tricky unix. Why does fork() have to be so complicated?
Well, it's very elegant really. It's one of the tools UNIX gives you to decompose a task into discrete modules, programs running in separate processes - but inheriting file descriptors and other common environmental stuff. And in some respects should feel familiar to a Haskell programmer - can't modify parent's environment, etc. For me, moral in the story should be that buffered I/O is not robust, for a socket device or anything like it (UNIX pipe, whatever.) That isn't about UNIX, it's just inevitable. Maybe your client is really going to need the timely EOF anyway, but the immediate problem was that the server wrote to the socket and the client couldn't see it. Because the client read is buffered. Not robust. Some programmers are so wedded to the buffered language platform I/O functions that they'll find a way to defeat the buffering or work around it. That can be "nonperformant" where the semantics of the read depend on buffering, like getLine; don't know what would happen with hGetContents. The path that makes sense to me is low level I/O (read/recv) that simply returns what's there, up to the specified limit. Donn