[ 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