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