finalizers on handles

Sittampalam, Ganesh ganesh.sittampalam at credit-suisse.com
Wed Jun 24 02:46:31 EDT 2009


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.)

I believe that from the point of view of each Haskell thread, the IO
will always be blocking (unless you explicitly used a non-blocking
call), but the GHC runtime actually handles the IO using select and
non-blocking calls, and so avoids blocking the entire program, and that
this doesn't vary between the threaded and non-threaded runtimes.

That's why I found it confusing that a program that just did IO could
behave differently on the two runtimes, until I found the bug in it.
Ideally, the program would have deadlocked on both runtimes.

Ganesh


=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 =============================================================================== 
 


More information about the Glasgow-haskell-users mailing list