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