quoth Evan Laforge <qdun...@gmail.com>,
...
> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
