[Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[Simon Marlow]

On 12/05/2011 18:24, dm-list-haskell-cafe at scs.stanford.edu wrote:
> At Thu, 12 May 2011 16:45:02 +0100,
> Simon Marlow wrote:
>>
>>>> There are no locks here, thanks to the message-passing implementation we
>>>> use for throwTo between processors.
>>>
>>> Okay, that sounds good.  So then there is no guarantee about ordering
>>> of throwTo exceptions?  That seems like a good thing since there are
>>> other mechanisms for synchronization.
>>
>> What kind of ordering guarantee did you have in mind?  We do guarantee
>> that in
>>
>>      throwTo t e1
>>      throwTo t e2
>>
>> Thread t will receive e1 before e2 (obviously, because throwTo is
>> synchronous and only returns when the exception has been raised).
>> ...
>> Pending exceptions are processed in LIFO order (for no good reason other
>> than performance)...
>
> I mean, suppose you have three CPUs, A, B, and C running threads ta,
> tb, and tc.  Then should the following order of events be permitted?
>
>              A                    B                     C
>        throwTo tc e1
>        throwTo tb e2
>                               catch e2
>                               poke p x
>                                                    peek p (sees x)
>                                                    catch e1
>
> I would argue that this is just fine, that one should rely on MVars if
> one cares about ordering.  But I'm not sure what "Pending exceptions
> are processed in LIFO order" means in the presence of relaxed memory
> consistency.

Oh, that can't happen.  A's first throwTo only returns when the 
exception has been raised in C - throwTo is like a synchronous 
communication in this sense.

We went to-and-fro on this aspect of the throwTo design a few times. 
The synchronous semantics for throwTo tends to be more useful for the 
programmer, but is harder to implement.  If you want asynchronous 
throwTo, you can always get it with forkIO.throwTo.

As far as memory consistency goes, we claim to provide sequential 
consistency for IORef and IOArray operations, but not for peeks and pokes.

> The reason I'm asking is that I want to make sure I never end up
> having to pay the overhead of an MFENCE instruction or equivalent
> every time I use unmaskAsyncExceptions#...

Right, I don't think that should be necessary.

Cheers,
	Simon