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