Web Images Videos Maps News Shopping Gmail more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Event system implementation
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  2 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Klaas-Jan Stol  
View profile  
 More options Jan 4 2006, 4:52 am
Newsgroups: perl.perl6.internals
From: parrotc...@gmail.com (Klaas-Jan Stol)
Date: Wed, 04 Jan 2006 10:52:14 +0100
Local: Wed, Jan 4 2006 4:52 am
Subject: Event system implementation
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Leopold Toetsch  
View profile  
 More options Jan 4 2006, 8:50 am
Newsgroups: perl.perl6.internals
From: l...@toetsch.at (Leopold Toetsch)
Date: Wed, 04 Jan 2006 14:50:12 +0100
Local: Wed, Jan 4 2006 8:50 am
Subject: Re: Event system implementation

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

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google