Uri Guttman <[EMAIL PROTECTED]> wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> Because of this, you have the event PMC for a Named event before the
> DS> event occurs and thus can wait on it. You *don't* have the event PMC
> DS> for an anonymous event, so you can't wait on it, all you can do is
> DS> semi-generically react once it's occurred.
> i think that should read "all parrot can do is react, assuming it is the
> one that set the signal handler (at the c/kernel level)".
I think, *if* we want an event PMC, we can alyways create one, when the
user code indicates that this kind of event should be handled.
$SIG{CHLD} = sub { 1; };
This could probably create the event PMC, associate the user callback
with it, enable SIGCHLD and be done with it. It's the same as with a
timer event.
*But* the first question is: do we really want PMCs in the inyards of
the event system (except callback sub PMCs)?
There are several issues:
- these PMCs need marking during DOD, which means that we have to mark
the event queue that might change under us
- event data may cross thread boundaries. This implies that event PMCs
(at least this kind) have to be shared PMCs (and all their contents)
Finally, if there is something like an "Unnamed Event" that needs
creating a PMC, we can't create the PMC in interrupt code. So the PMC
has to be preallocated. But how many PMCs will you provide? In which
interpreter's arena are these precreated?
For now I think, it's not a good idea to have the internals of an event
as a PMC.
leo
