chromatic wrote:
From the wiki at
http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks :
* Deprecate "rethrow".
The replacement seems to be that an exception handler declines to handle an
exception. This is the default behavior; an exception handler explicitly
notifies the scheduler that it has handled (or will handle) the exception by
using the handled opcode. PDD 25 suggests that there are Task PMCs which
represent or encapsulate these exceptions.
Presumably the handled opcode will remove the exception Task from the
scheduler and resume execution at the appropriate point. Presumably also the
declining to handle an exception (the replacement for rethrow) will cause the
scheduler to move to the next exception handler in its list? If so, how do
we model this control flow?
I planned to handle these parts of the code myself, so I only noted
enough to use as a checklist when I'd finished the task.
Essentially, we're ripping out the entire underpinning of the old
exception system, and replacing it with the concurrency scheduler, while
still preserving the same interface. The deprecation of "rethrow" will
have to come towards the end of the transition, after exceptions are
moved over to the concurrency scheduler (it can be deleted when it no
longer does anything).
More on control flow tomorrow.
* Change 'real_exception' to use concurrency scheduler.
Does this mean to change the opcode and its backing functions to create a Task
PMC, an Exception PMC, or both? If so, where does control flow go with the
scheduler works asynchronously? Or does the scheduler handle exceptions as
they occur in real-time? A later task:
Exception PMCs are polymorphically substitutable for Tasks. (Event PMCs
are also.) Ultimately Exception may inherit from Task, but for now it's
not necessary.
* 'throw_exception' and 'rethrow_exception' change to something more
like 'Parrot_cx_handle_tasks'.
... suggests that these functions may schedule the exception (if necessary)
and then immediately run the scheduler in the current interpreter.
Yes.
* 'push_exception' changes to 'Parrot_cx_add_handler'.
The latter function already exists. Merge or rename? Note that exception
handling has to stop looking in interp->dynamic_env for this to work.
'push_exception' is what registers the exception handler for later
lookup (terrible name for it). With the new implementation,
'Parrot_cx_add_handler' will register the exception handler (with the
concurrency scheduler). IIRC, all it needs is to change the check for a
valid handler type to also allow exception handlers (don't have time to
verify at the moment).
* 'count_exception_handlers' changes to access the concurrency scheduler (a
simple method call or keyed access).
There's currently no way of filtering handlers in the scheduler by parentmost
type; should there be one?
Yes.
Allison
