On Tue, Jul 26, 2011 at 1:25 AM, Edward Z. Yang ezy...@mit.edu wrote:
Hello Brandon,
The answer is subtle, and has to do with what references are kept in code,
which make an object considered reachable. Essentially, the main thread
itself keeps the MVar live while it still has forking to do,
On Sun, Jul 24, 2011 at 10:02 PM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons
brandon.m.simm...@gmail.com wrote:
What I think I've learned here is that the BlockedIndefinitelyOnMVar
exception is raised in all the blocked threads at once
On Sun, Jul 24, 2011 at 10:07 PM, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Felipe Almeida Lessa's message of Sun Jul 24 22:02:36 -0400
2011:
Does anything change if you somehow force a GC sometime after good2?
Perhaps with some calculation generating garbage, perhaps with
Hello Brandon,
The answer is subtle, and has to do with what references are kept in code,
which make an object considered reachable. Essentially, the main thread
itself keeps the MVar live while it still has forking to do, so that
it cannot get garbage collected and trigger these errors.
Here
I'm trying to really understand how the BlockedIndefinitelyOnMVar
exception works in concurrent code as I would like to rely on it as a
useful runtime signal in a concurrency library I'm working on.
Here is some code illustrating a function restoring an abandoned lock
in a single-threaded program
On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons
brandon.m.simm...@gmail.com wrote:
What I think I've learned here is that the BlockedIndefinitelyOnMVar
exception is raised in all the blocked threads at once as it were.
That despite the fact that the handler code in 'lockPrint' restores
the
Excerpts from Felipe Almeida Lessa's message of Sun Jul 24 22:02:36 -0400 2011:
Does anything change if you somehow force a GC sometime after good2?
Perhaps with some calculation generating garbage, perhaps with
performGC. IIRC, the runtime detects BlockedIndefinitelyOnMVar on GC.
But I'm
