From: Jerry Gay (via RT) <[EMAIL PROTECTED]>
Date: Sat, 11 Nov 2006 19:15:52 -0800
the code below is broken while testing alarm with exception handlers.
i wish i could debug it, but it hurts my brain. maybe somebody smart
(bob?) about exception handlers can have a look and tell me what's
what.
~jerry
Thanks for the plug, but this is my first look at events, where I'm
definitely *not* smart. However, I do see that do_event in src/events.c
is indeed calling an inferior runloop to run the event sub. And that
means that throwing an exception from the alarm sub just won't work.
But should we expect it work? In general, timer code can't assume
that the right handler will get control. You may have bound a handler
that you expect will catch the error, but what if some other module you
are using happens to bind an overly-general handler at just the wrong
moment? It just doesn't seem robust.
Of course, this doesn't really apply to your test script. And
exceptions in timer events really ought to work in any case. But the
right way to fix it involves turning a nontrivial amount of src/events.c
code inside out, and I don't yet have a good way to do that. Thanks for
pointing this out, though; I will factor this case into my thinking on
this problem.
-- Bob Rogers
http://rgrjr.dyndns.org/
P.S. For the record, it would not be hard to teach Continuation:invoke
to cross runloop barriers for exception handling (among others), since
such continuations can only go down the stack. But I've been resisting
the temptation, since we'd still need to do the same code rewriting to
support upward continuations, including coroutines. Inferior runloops
are evil.
