What does interruptibility mean exactly?

[scooter.phd at gmail.com]

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 <v.dijk.bas at gmail.com>
Date: Tue, 15 Jun 2010 20:36:44 
To: Simon Marlow<marlowsd at gmail.com>
Cc: <glasgow-haskell-users at haskell.org>; Don Stewart<dons at galois.com>
Subject: Re: What does interruptibility mean exactly?

On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 15/06/2010 09:00, Bas van Dijk wrote:
>>
>> On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart<dons at galois.com>  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 at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users