finalizers on handles

Simon Marlow marlowsd at gmail.com
Tue Jun 23 09:41:41 EDT 2009


On 20/06/2009 21:46, Ganesh Sittampalam wrote:

> I recently spent a while debugging a problem where a program deadlocked
> in the non-threaded runtime, but ran fine in the threaded runtime,
> despite the program having no blocking FFI calls, and boiled it down to
> the following test case:
>
> module Main(main) where
>
> import System
> import System.IO
> import System.Process
>
> main = do
> (ih, oh, _, _) <- runInteractiveProcess "cat" [] Nothing Nothing
> comphszp <- hGetContents oh
> print (length comphszp)
> -- hClose ih -- with this line they both deadlock
>
> The reason for the deadlock is fairly straightforward; since ih isn't
> closed before comphszp is fully demanded, no progress can be made. My
> guess is that the threaded runtime is fine because ih is dead at that
> point, and the finalizer for ih gets a chance to run, closing ih.
>
> If I'm right, is it really sensible for every handle to have this
> finalizer? Closing a pipe has externally visible side effects beyond
> just the release of resources, so it doesn't seem like it should happen
> non-deterministically.

Interesting example.  So what should we do?  Don't finalize an FD if it 
might have an externally visible effect?  That seems a bit extreme.

Anyone else have any thoughts on this?

Cheers,
	Simon


More information about the Glasgow-haskell-users mailing list