BlockedIndefinitelyOnMVar exception - Haskell-Cafe - Haskell.org

newer
Byte Histogram

BlockedIndefinitelyOnMVar exception

older
Re: [Haskell-cafe] NOT Iteratee,...

Mitar

31 Mar 2011 31 Mar '11

3:29 a.m.

Hi! Is there a way to disable throwing BlockedIndefinitelyOnMVar exceptions? Because I am doing small program where I do not care if some threads block. As at the end user will have to interrupt the program anyway. Mitar

Reply

Sign in to reply online Use email software

Show replies by date

Edward Z. Yang

31 Mar 31 Mar

5:41 a.m.

I don't know if there's a way to disable it, but you can wrap all your spawned threads with an exception handler that catches BlockedIndefinitelyOnMVar and ignores it. If the thread blocks indefinitely, it's as good as dead, so there won't be any difference in behavior. Cheers, Edward

Reply

Sign in to reply online Use email software

Gregory Collins

6:03 a.m.

I find this behaviour a little annoying. Sometimes I *want* the thread to block indefinitely! I.e. I want it to block until it receives a KillThread exception. Is there a better way to accomplish that without waiting on an MVar which will never fill? As a workaround what I've been doing lately is stashing another reference to the mvar somewhere else (I'm guessing the trigger condition for "BlockedIndefinitelyOnMVar" is "blocked and mvar refcount == 1"). G On Thu, Mar 31, 2011 at 11:41 AM, Edward Z. Yang wrote:

I don't know if there's a way to disable it, but you can wrap all your spawned threads with an exception handler that catches BlockedIndefinitelyOnMVar and ignores it. If the thread blocks indefinitely, it's as good as dead, so there won't be any difference in behavior.

Cheers, Edward

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Gregory Collins

Reply

Sign in to reply online Use email software

Neil Brown

6:15 a.m.

On 31/03/11 11:03, Gregory Collins wrote:

I'm guessing the trigger condition for "BlockedIndefinitelyOnMVar" is "blocked and mvar refcount == 1" It's not simply a reference count (the thread that's blocked forever can hold multiple references to the MVar and it's still blocked indefinitely). Here's how I understand it.

Blocked threads are not counted as roots during the GC. Therefore for a blocked thread to survive a round of GC without being collected, something reachable from a root has to point to the thread. The only thing that points to a thread blocked on an MVar (same idea for TVars, too) is the MVar itself. Therefore, something that's reachable from a GC root (a running thread is a root, I think) must point to the MVar to allow the thread to survive the GC. If a thread would be garbage collected, it is instead woken up with a BlockedIndefinitelyOnMVar exception. I think if you put an MVar into a StablePtr, that may prevent threads waiting on it from being woken up with that exception. Thanks, Neil.

Reply

Sign in to reply online Use email software

Brandon Moore

10:37 a.m.

From: Gregory Collins

Sent: Thu, March 31, 2011 5:03:09 AM

I find this behaviour a little annoying. Sometimes I *want* the thread to block indefinitely! I.e. I want it to block until it receives a KillThread exception. Is there a better way to accomplish that without waiting on an MVar which will never fill? As a workaround what I've been doing lately is stashing another reference to the mvar somewhere else (I'm guessing the trigger condition for "BlockedIndefinitelyOnMVar" is "blocked and mvar refcount == 1").

If you plan to send an exception, you must have the ThreadId saved elsewhere, which should prevent the BlockedIndefinitelyOnMVar exception. http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.3.1.0/Control-C... Brandon

Reply

Sign in to reply online Use email software

Mitar

3:06 p.m.

Hi! On Thu, Mar 31, 2011 at 4:37 PM, Brandon Moore wrote:

If you plan to send an exception, you must have the ThreadId saved elsewhere, which should prevent the BlockedIndefinitelyOnMVar exception.

But this behavior is something they wish to remove in future versions as not-wanted? Mitar

Reply

Sign in to reply online Use email software

Brandon Moore

3:41 p.m.

----- Original Message ----

From: Mitar To: Brandon Moore Cc: Gregory Collins ; Edward Z. Yang ; Haskell Cafe Sent: Thu, March 31, 2011 2:06:31 PM Subject: Re: [Haskell-cafe] BlockedIndefinitelyOnMVar exception

Hi!

On Thu, Mar 31, 2011 at 4:37 PM, Brandon Moore wrote:

...
If you plan to send an exception, you must have the ThreadId saved elsewhere, which should prevent the BlockedIndefinitelyOnMVar exception.

But this behavior is something they wish to remove in future versions as not-wanted?

The BlockedIndefinitelyOnMVar exception is only supposed to be sent if the thread is known to be deadlocked. If it is possible that another thread might wake it by sending an asynchronous exception, it's probably not appropriate to send it the BlockedIndefinitelyOnMVar exception. Even if it holding a ThreadId didn't always keep the target thread around, it would still have to preserve the thread if it was possible you might eventually use throwTo on the threadId (even killThread technically raises a catchable exception). I note you could at least preemptively prune the stack down to the topmost exception handler, and collect at least some garbage that way. Also, that note has been in the documentation at least since GHC 4.06 so I don't expect the situation to change any time soon! (3.02 didn't yet implement killThread, according to docs in the source package). http://www.haskell.org/ghc/docs/4.06/hslibs/sec-concurrency-basics.html Brandon

Reply

Sign in to reply online Use email software

5164

Age (days ago)

5164

Last active (days ago)

Download

6 comments

5 participants

tags

participants (5)

Brandon Moore
Edward Z. Yang
Gregory Collins
Mitar
Neil Brown