Why we can make a MessageBlackHole an IND without setting the indirectee? Is this used to remove (by skipping) a MessageBlackHole from
#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165 -------------------------------------+------------------------------------- Comment (by simonmar): the queue? (because actually removing would be impossible as we don't have a prev field in MessageBlackHole?) Yes, exactly.
As far as I understand, a BLACKHOLE can become a BLOCKING_QUEUE (in messageBlackHole()), and queue of a BLOCKING_QUEUE is for threads that are blocked on this BLACKHOLE.
Why do we have a bh field in messageBlackHole? We could pass the bh as a
Just to be clear, A BLACKHOLE doesn't "become" a BLOCKING_QUEUE, the BLACKHOLE's indirectee field points to the BLOCKING_QUEUE. parameter to messageBlackHole() and bh would the blackhole that we just looked at to find the MessageBlackHole. A MessageBlackHole is sent to another capability, which needs to know which BLACKHOL to add it to.
Why do we need a list of BLOCKING_QUEUEs? Is this only to be able to implement checkBlockingQueues()? The comments around checkBlockingQueues() say
See this comment in `messageBlackHole()`: {{{ // All BLOCKING_QUEUES are linked in a list on owner->bq, so // that we can search through them in the event that there is // a collision to update a BLACKHOLE and a BLOCKING_QUEUE // becomes orphaned (see updateThunk()). }}}
but I don't understand how can owner of a BLACKHOLE not point to our capability if we BLACKHOLEd it.
A BLACKHOLE can be updated by another thread at any time. The fact that it is a BLACKHOLE is not an exclusive ownership. We use compare-and-swap to install the BLACKHOLE in `threadPaused()`, but another thread might already be evaluating the thunk and will update it with the value later, and we don't use a compare-and-swap when updating because that would be too expensive. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15508#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler