Event system implementation

[Klaas-Jan Stol]

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), 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.

So, this brings the danger of introducing delays between sending an
event, and their handling (I'm sure this delay is not that bad, but still).
Then, I remembered, if an exception is thrown, this is handled
immediately by the exception handler (the one the user should have
pushed onto the control stack). So, exceptions are handled immediately,
while events are not.

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).

Thanks in advance for reading this,

klaas-jan

[Leopold Toetsch]

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