[ ghc-Bugs-429736 ] "No threads to run" ignores finalizers

noreply@sourceforge.net noreply@sourceforge.net
Mon, 04 Jun 2001 09:29:45 -0700


Bugs item #429736, was updated on 2001-06-02 22:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=429736&group_id=8032

Category: Runtime System
Group: 5.00
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Manuel M. T. Chakravarty (chak)
>Assigned to: Simon Marlow (simonmar)
>Summary: "No threads to run" ignores finalizers

Initial Comment:
This is re my posting under the subject "Weak pointers,
garbage collection & deadlocks" on
glasgow-haskell-users.

Basically, the problem is that finaliser threads that
the next GC would generate aren't taken into account
when determining whether there are any more threads to
run.

I attach a program reproducing the error.

----------------------------------------------------------------------

>Comment By: Simon Marlow (simonmar)
Date: 2001-06-04 09:29

Message:
Logged In: YES 
user_id=48280

Fixed: now if we get a deadlock, we try a major GC and if 
this creates any threads we carry on.

Note that frequently relying on this behaviour is likely to 
be inefficient because of the forced major GC.

----------------------------------------------------------------------

Comment By: Manuel M. T. Chakravarty (chak)
Date: 2001-06-03 07:46

Message:
Logged In: YES 
user_id=10359

PS: The problem mentioned in the last comment can be solved
by using a StablePtr on the MVar, which is freed in the
finalisers - all quite yucky.


----------------------------------------------------------------------

Comment By: Manuel M. T. Chakravarty (chak)
Date: 2001-06-03 06:50

Message:
Logged In: YES 
user_id=10359

Actually, I think, the situation is even worse than I first
thought.  When in the example program that I attached
earlier you enable the `gcThread', the program will behave
correctly, but this is unfortunately *not* guaranteed.

If you are unlucky, you'll get an ``thread blocked
indefinitely'' instead.  The reason seems to be is that the
MVar on which the main thread blocks is only accessible via
the finaliser.

There seems to be a race condition here.  The analysis in
this comment is based on my observation in the larger
program that pointed me to the problem, but the program is
quite complex, so I might have misinterpreted something.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=429736&group_id=8032