Re: Exceptions and Concurrency Questions

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

• Exceptions and Concurrency Questions by chromatic
• Re: Exceptions and Concurrency Questions by Allison Randal
• Re: Exceptions and Concurrency Questions by Allison Randal