Klaas-Jan Stol wrote:
> Hi,
> As you know, I'm currently busy writing a paper on the architecture of
> Parrot, and during my attempt to describe the exception sub-system,
> something came to mind. I'm not sure if the event system is fully
> operational (I thought it was already implemented),...
The implementation is more a proof of concept than fully operational.
See also docs/dev/events.pod.
> ... but I do know the
> plan was to check at a regular base if there were any events generated.
> So, instead of checking after each opcode if an event is pending, this
> is done every few opcodes in order to safe
> time.
Yup basically.
> Of course, I'm no expert in these things, so please correct me if I'm
> wrong. But I'm wondering, why the event system hasn't been implemented
> this way, as an event also has an event handler (just like an exception
> has an exception handler). (I'm sure there are a lot of implementation
> details involved, but I'm talking about the big picture here; making
> sure events are handled immediately).
The problem with events (or signals) is that they arrive asynchronously
and second that signals are per process and not per thread. While now
you could {sig,}longjmp (aka throw an exception) after finding the
interpreter that handles the event, it would be impossible to resume the
interrupted operation. Also note that there could be some half-updated
state, which would make all further code utterly unsafe to execute.
E.g. the signal has happened in C code while resizing an array, which
the event handler wants to read.
That means, you can continue the run-loop at a different location (the
event handler) only from within the run-loop itself.
> Thanks in advance for reading this,
> klaas-jan
leo