On 15/06/2010 09:00, Bas van Dijk wrote:

On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote:

...

v.dijk.bas:

...

Hello,

I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked?

newEmptyMVar>>= \mv -> block $ putMVar mv x

The documentation in Control.Exception about interruptible operations[1] confused me:

"Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..."

I think the best definition of interruptible is in this paper:

www.haskell.org/~simonmar/papers/async.pdf

Section 5.3

Thanks for the link Don! Next time I will re-read the paper before asking ;-)

The definition makes it clear indeed:

"Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE"

So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago.

This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+). I'll update the docs to make that clear. The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible. Cheers, Simon

A later quote from 5.3 emphasizes the definition even more:

"...an interruptible operation cannot be interrupted if the resource it is attempting to acquire is always available..."

The following darcs patch makes the definition of interruptibility in the documentation in Control.Exception a bit clearer in this regard:

http://bifunctor.homelinux.net/~bas/doc-interruptibility.dpatch

Regards,

Bas _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

It seems to me that the documentation could be further refined: An acquisition operation cannot be interrupted when the requested resource is available; the resource is successfully acquired and the subsequent computation can proceed. On the other hand, if the resource is unavailable, then the acquisition operation is in a blocked state and can be interrupted. I'm not sure that this is the exact phrasing, but it does convey the meaning a bit more clearly. Also missing is that interruptable implies restartable. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Bas van Dijk Date: Tue, 15 Jun 2010 20:36:44 To: Simon Marlow Cc: ; Don Stewart Subject: Re: What does interruptibility mean exactly? On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow wrote:

On 15/06/2010 09:00, Bas van Dijk wrote:

...

On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart  wrote:

...

v.dijk.bas:

...

Hello,

I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked?

  newEmptyMVar>>= \mv ->  block $ putMVar mv x

The documentation in Control.Exception about interruptible operations[1] confused me:

"Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..."

I think the best definition of interruptible is in this paper:

   www.haskell.org/~simonmar/papers/async.pdf

Section 5.3

Thanks for the link Don! Next time I will re-read the paper before asking ;-)

The definition makes it clear indeed:

"Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE"

So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago.

This is currently true for takeMVar/putMVar but it is no longer true for throwTo (in 6.14+).  I'll update the docs to make that clear.  The reason is that throwTo now works by message passing when the target is on another CPU, and we consider a thread that is waiting for a response to a message to be blocked - even if the throwTo can in fact proceed immediately because the target is interruptible.

Thanks for the heads-up. BTW I just released threads-0.3 which, among other things, uses MVars again for waiting for the termination of a thread: http://hackage.haskell.org/package/threads-0.3 Regards, Bas _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users