Concurrency

[David Roundy]

On Sun, Apr 02, 2006 at 11:38:23PM -0700, John Meacham wrote:
> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote:
> > I'd like to be sure that asynchronous exceptions can get into the
> > standard.  They require concurrency, but I'm not sure that they're
> > included in John's page.
> 
> I am assuming you mean supporting the 'throwTo' primitive, which can be
> caught in the IO Monad?

Yeah, and block, which you need in order to avoid being interrupted by such
exceptions.

> Asynchronous is something of a misnomer, they are only as asynchronous as
> your threading model, so in a standard cooperative system, they would
> only be delivered in the IO monad simply for the fact that that is the
> only time some other thread would be running in order to call 'throwTo'.

Yeah, but they're always asynchronous in the presense of block, in the
sense that if you throw them it could be quite a while before they get
received.

> there are also a few questions we would want answered for the spec
> 
>  * do we require the thrower to 'block' until the signal is recieved?
>   (only relevant to pre-emptive implementations)

That wouldn't seem necesary to me.

>  * what happens if mutilple thrown exceptions "pile up" before the
>    catcher gets to them?

That's definitely a good question.  (and I've no answer, but there ought
to be one.)

>  * what happns to exceptions that fall off the end of threads, or the
>    main thread? (should be answered anyway)

You mean if the thread terminates before the exception is handled?

>  * promtness? how much work is the target allowed to do before it "sees"
>    the exception? pthreads allows an implementation to delay processing
>    an exception to a "cancellation point" do we want the same thing in
>    haskell? if not, how will this affect OS threaded implementations?

I don't see that there need be any guarantee of promptness, as the coder
can always delay manually using block.

> > It would also be nice to address signal behavior, and by default state that
> > signals should be converted to asynchronous exceptions.  The only downside
> > I can see of this as default behavior would be that in cooperative systems
> > the response to a sigTERM might be very slow.  But the benefits in terms of
> > having bracket et al "just work" would be huge.  Signals aren't entirely
> > portable... but then I'd say a lot of the purpose of the standard is to
> > allow the writing of portable code, which means addressing signals.  And
> > Windows (which doesn't have signals) has its own weird way of dealing with
> > a keyboard interrupt that also ought to be converted into an asynchronous
> > exception.
> 
> Yeah, I would like to deal with signals too, but a concise clear way
> does not occur to me off the top of my head.

I like the way I do it in darcs, which is to throw an asynchronous
exception to the main thread in the signal handler.  It seems very clean
and haskelly.  So instead of installing a signal handler, you'd just catch
these exceptions.  One could introduce an API to redirect them to a
different thread, perhaps, but in general, it seems like it would require
very little work and work very nicely.

The main catch I see would be dealing with interrupts and the FFI.  But I
guess that's not really any different from dealing with threading and the
FFI in general, in that one might like to be able to interrupt a
(presumably lengthy) FFI call from another thread, and I'm not aware of an
API to do this...

> There is (almost) no need to insert yields anyway, in order to meet the
> progress guarentee, a cooperative system must possibly yield at any
> potentialy blocking IO action. this ensures no time is actually wasted,
> haskell threads are always making progress and when one is waiting for
> something, another picks up the slack.

Okay, I hadn't realized about the potentially blocking IO actions having
this effect (or hadn't read carefully enough).
-- 
David Roundy
http://www.darcs.net