"No threads to run" ignores finalizers

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.

changed weight to 5

Attached file test.2.hs ($56).

added RTS Tbug Trac import labels

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.

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.

closed

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.

mentioned in issue #7970 (closed)

mentioned in commit 1ae72ac4

reopened

changed the description

unassigned @simonmar

Reopening as per previous commit message.

Trac metadata

Trac field	Value
TypeOfFailure	- → OtherFailure
Resolution	ResolvedFixed → Unresolved
CC	→ simonmar
Operating system	- → Unknown/Multiple
Architecture	- → Unknown/Multiple

closed

We shouldn't consider this a bug, since we deliberately decided to go with the alternative behaviour.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

added Pnormal label