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
