As I said during #parrotsketch [1], I have recently (and belatedly)
learned that exception handling is planned for a major shakeup. (FWIW,
I now see that is because exceptions are being recast as events; I had
assumed that PDD24 was just about asynchronous events. Since PDD23
hasn't changed much in the last year, it slipped past my radar.)
However, having read the current versions of pdd23_exceptions.pod,
pdd24_events.pod, and pdd25_concurrency.pod (albeit perhaps not
thoroughly enough), I still have many questions; the most salient ones
are below. Please don't hesitate to ask if any of this is unclear.
(I'm not expecting immediate answers in any case.)
1. In the "schedule" opcode item, it says the following:
If the concurrency scheduler for this interpreter
(thread/clustered instance) is linked to another "primary"
concurrency scheduler, this will pass along the event to the
primary.
Para 3 in the "Implementation" section says:
In more complex cases (particularly on multi-processor
machines), the concurrency scheduler runs in its own thread.
However, I didn't see a mechanism for associating handlers or events
with a particular thread. How do I implement synchronous (nonthreaded)
exception handling on a multiprocessor? pdd23_exceptions.pod seems to
assume single-threading; is this slated to change? (Are there any
languages that really do exception handling concurrently? Even in
Erlang, errors within each process seem to happen synchronously, and are
propagated between processes only as messages [2].)
2. The "Event Type Hierarchy" section doesn't include "Exception" as
a type. Is this an oversight? How are user-defined types introduced
into the exception type hierarchy? In particular, is it possible to
define new groupings, or add to old ones?
3. I assume "the core code object of the event handler" is what gets
called when the event handler is invoked? Can it be a closure (as
pdd23_exceptions.pod seems to imply)? What happens if it is (or it
invokes) a continuation; do we get sent back to that thread? In the
original interpreter, or the concurrency scheduler interpreter?
4. In Common Lisp, one can re-signal a condition in a handler [3],
i.e. while it is already being signalled (thrown):
(defun test-case ()
(handler-bind ((error #'(lambda (condition)
(signal condition)
;; Not handled, so we get it.
(format t "Error ~A was not handled.~%"
condition)
(return-from test-case nil))))
(do-something-hairy)))
This of course requires that the handler not be in its own scope (just
as for Perl 6), so that the second "signal" can propagate outward. Is
that handled automatically, or do event handlers have to disestablish
themselves explicitly? I notice that "rethrow" is going away; is it OK
to just "throw" the same exception again in order to implement "signal"?
5. On the flip side of the issue, if do-something-hairy creates a
continuation that gets called after exiting test-case, how does the
handler established by test-case get re-established?
6. As also mentioned in #parrotsketch, I (not to mention Coke and
Patrick ;-) need something equivalent to "pushaction" in order to
implement CL unwind-protect. I am also currently using it to implement
dynamic global variable binding, but that is a kludge. (As discussed
last fall [4], I hope to replace the kludge with a mechanism that also
uses dynamic_env, so news of its planned demise is worrying.) For both
applications, though, I need something that also respects continuations,
i.e. they must be triggered when blocks are exited via continuation
calling. So, how should I do this in the brave new world?
My apologies if this is obscure, but I figured I had better speak up
ASAP, and post clarifications as needed.
-- Bob Rogers
http://rgrjr.dyndns.org/
[1]
http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200804/irclog.parrotsketch.20080429
[2] Joe Armstrong, "Programming Erlang", chapter 9.
[3] See the "Default Handling" section of Kent Pitman, "Condition
Handling in the Lisp Language Family",
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
[4]
http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/158e5fbcc84479a8/d7cb1751eea6b4c7?hl=en&lnk=st#d7cb1751eea6b4c7
