Concurrency

[David Roundy]

On Fri, Mar 31, 2006 at 04:41:06AM -0800, John Meacham wrote:
> I have tried to summarize the current thinking into a proposal on the
> wiki.
> 
> http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency

Just to pop up my head: this looks good to me.  I've only used concurrency
a very little bit, except for asynchronous exceptions and a bit of
signal-handling magic, so I'm not clear on all the details of one proposal
or another, but am glad to see that in some form it's looking like all the
haskell implementors can agree on concurrency.

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.

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.

It might be nice to have a third alternative option for cooperative systems
in which all standard library IO routines automatically yield after
running, to make it easier to port code written for a preemptive system to
a cooperative compiler without manually inserting yields all over the
place.  It wouldn't give strong guarantees, but would seem convenient.  It
might also relax the requirement that yield will always switch threads,
allowing the implementation to decide not to switch too frequently if yield
is called very often.  Or introduce a maybe_yield that is weaker.
--
David Roundy
http://www.darcs.net