[GHC] #7970: Thread GC frees roots before thread actually finishes

[GHC]

#7970: Thread GC frees roots before thread actually finishes
---------------------------------+------------------------------------------
    Reporter:  joeyadams         |       Owner:  simonmar        
        Type:  bug               |      Status:  new             
    Priority:  high              |   Milestone:  7.8.1           
   Component:  Runtime System    |     Version:  7.6.3           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  Runtime crash   
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:  7170              |  
---------------------------------+------------------------------------------

Comment(by simonmar):

 > It only makes sense to call a thread "unreachable" if it will never run
 again.

 Which is the case now - at the point where the thread is unreachable, it
 will never run again.  So we send it an exception to tell it (at which
 point it runs again of course, but if it were not for the exception it
 would not run).

 The specific problem in this ticket is the interaction between threads and
 weak pointers.  Right now, it is the case that

  * a reference from the finalizer of a weak pointer to a thread makes the
 thread reachable, even if the key of the weak pointer is not reachable.

 This means that you can have a thread blocked waiting for a finalizer to
 run.  There's an alternative design, which would make the program in this
 ticket work:

  * a reference from a thread to a weak pointer makes the weak pointer
 reachable, even if the thread itself is not reachable.

 You can choose one of these, or neither, but not both.  The reason is that
 the GC must do these steps in some order:

  * decide which weak pointers are unreachable, and make their finalizers
 alive
  * decide which threads are unreachable, and then make them alive

 if we did both at the same time, you would get *neither* of the behaviours
 above.

 So I think what the example in this ticket argues for is switching the
 order.  I'm fine with that (I buy the argument) but it does potentially
 break the use case of having a thread blocked on a finalizer. I'm not sure
 whether anyone actually does that or not.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7970#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler