
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