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? * 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: * '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. * '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. * '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? More later, -- c
