On 24/06/2009 07:33, Brandon S. Allbery KF8NH wrote:
On Jun 24, 2009, at 02:27 , Sittampalam, Ganesh wrote:
Brandon S. Allbery KF8NH wrote:
Sure - but it hurts more when in some environments you get away with
it and others you don't.
You'll still have that though, it'll just be a different set of
environments. The next failure mode after this one is writing more
than _PIPE_BUF down ih; you'll deadlock in the write when in blocking
mode, in non-blocking mode it depends on how the runtime handles
partial writes.
I'd hope for consistency across the GHC runtimes though.
You can hope, but I get the impression blocking/non-blocking maps to
threaded/non-threaded respectively in which case all bets are off.
(Unless the ghc runtime guarantees some specific behavior here.)
GHC uses non-blocking mode for all FDs that are "internal", i.e. not
shared with external processes. This is the case for both the threaded
and non-threaded RTSs. The difference between blocking/non-blocking
mode and the size of PIPE_BUF should be mostly invisible to the Haskell
programmer (although see http://hackage.haskell.org/trac/ghc/ticket/3316
for a bug we have in this area, which I fixed yesterday).
There's one exception: if GHC is forced to use blocking mode on a
particular FD, and you're using the non-threaded RTS, then a large write
using hPutBuf may block all Haskell threads. There doesn't seem to be
much we can do about this, except to use the threaded RTS or lobby the
Linux kernel guys for a better API.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
