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 I split it into 3 parts. the standard - all haskell' compilers must implement optional preemption - ability to preempt pure code, fairness guarentees, interleaved evaluation operators (merge, nmerge) optional OS threads - bound threads, SMP, reentrant concurrent FFI calls supported. comment or modify it at will. John -- John Meacham - ⑆repetae.net⑆john⑈
I just realized that my mailer futzed this one and its headers don't match where it was actually sent. so if you are responding to it, the mail most likely is not going out to the list. make sure it is to haskell-prime and not hasuell-prime. John -- John Meacham - ⑆repetae.net⑆john⑈
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
Hello David, Saturday, April 1, 2006, 4:31:05 PM, you 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.
this an another ticket
It would also be nice to address signal behavior, and by default state that signals should be converted to asynchronous exceptions.
it was surprise for me that i don't receive ^Break as an exception and should do something special to handle this. on the other side, in more complex setting involving lengthy FFI calls, ghc's solution is the only way to let know to this FFI function that it should abort his execution -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
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? 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'. There are no issues with implementing them in a fully cooperative system, in fact they are much much easier, you just need to set a flag on the target thread and when it resumes it checks the flag and throws the exception itself. The run-time cost of checking the flag will be consumed by the block that must have occured to being with. however, in a preemptive one, it is less clear whether they may be delivered right away or not and what the implementation costs are, as threads arn't necessarily blocked at a point where they can happily deal with an exception. Perhaps the yhc guys have thought about the problem? 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) * what happens if mutilple thrown exceptions "pile up" before the catcher gets to them? * what happns to exceptions that fall off the end of threads, or the main thread? (should be answered anyway) * 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?
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.
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.
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. The only time a manual 'yield' would be needed is when you had a long series of actions or a loop with no "actual" IO in them. meaning reading/writing handles, calling foreign concurrent functions, or any other potentially blocking operation. of course, such a thing as you say is totally okay by the standard. there is certainly wiggle room between strict cooperative and pre-emptive. pthreads has a sort of 'weaker yield' that just checks for exceptions but doesn't necessarily yield. John -- John Meacham - ⑆repetae.net⑆john⑈
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
On Monday 03 April 2006 08:38, 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?
There is also divide-by-zero and related stuff that is thrown from pure code. Ben
On Mon, Apr 03, 2006 at 05:22:34PM +0200, Benjamin Franksen wrote:
On Monday 03 April 2006 08:38, 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?
There is also divide-by-zero and related stuff that is thrown from pure code.
those are 'ImpreciseExceptions' which is a different extension. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
On Mon, Apr 03, 2006 at 05:22:34PM +0200, Benjamin Franksen wrote:
On Monday 03 April 2006 08:38, 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? There is also divide-by-zero and related stuff that is thrown from pure code.
those are 'ImpreciseExceptions' which is a different extension.
The asynchronous exceptions extension is morally an extension to the imprecise exceptions extension :-) You /can/ do the former without the latter, but the semantics we gave assumed both were in play. A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 adams-moran@galois.com
participants (5)
-
Andy Adams-Moran -
Benjamin Franksen -
Bulat Ziganshin -
David Roundy -
John Meacham