GHC Trac Home
GHC Git Repos
Report a bug
Mailing Lists & IRC
The GHC Team
GHC Status Info
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
May 23, 2012 4:13:41 AM (
Any thunk evaluation may encounter a blackhole - a thunk under evaluation. When a thread encounters a thunk, the vanilla GHC suspends the thread until the thunk finishes evaluation. Similar to the solutions developed above, we can utilize the scheduler actions to yield control to another thread from the user-level scheduler. However, since the scheduler actions themselves are implemented in Haskell code, which can encounter blackholes, we might encounter situations where the user-level scheduler becomes blocked on a thread that it is scheduling, resulting in a deadlock. Moreover, the thread evaluating the blackholed thunk (blackhole owner) might be running on the same or a different capability as the thread entering the blackhole. This complicates the problem of potentially resuming a blackholed thunk's evaluation. In addition to all of these concerns, we would like the common case - a thunk finishing evaluation without being blackholed - to be fast.
When a thread enters a blackhole, there are essentially 3 parameters that we need to consider:
1. '''Is the thread manipulating a scheduler?''' since schedulers are implemented in Haskell code, there isn't a clear distinction between the scheduler and the rest of the program. As an approximation, we assume that whenever a thread is in the middle of a PTM transaction, it is potentially manipulating the scheduler.
2. '''Is this an upcall thread?''' In the common case, when a thread enters a blackhole, we utilize its scheduler actions to block it on the blackhole's blocking queue. But an upcall thread, evaluating scheduler actions from the RTS is not associated with any scheduler and hence does not have scheduler actions. This case must be handled separately.
3. '''Is the blackhole owner on current capability?''' If the blackhole owner is on the current capability, then the blackhole owner is currently suspended. Otherwise, thunk evaluation is potentially progressing on another capability.
=== Asynchronous Exceptions ===