finalizers on handles

[Simon Marlow]

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