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

[dm-list-haskell-cafe at scs.stanford.edu]

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.

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#...

David