john at repetae.net
Mon Apr 3 02:38:23 EDT 2006
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
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
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 Meacham - ⑆repetae.net⑆john⑈
More information about the Haskell-prime