At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
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.

Which is swell, except.... the problem you run into here is persistent signal handlers. (Which you really do need, or you lose signals, which is bad) This goes for GUI event handlers too. You can pre-allocate a PMC, but then you need to make sure the


*But* the first question is: do we really want PMCs in the inyards of
the event system (except callback sub PMCs)?

We need something. Not having a PMC doesn't make things any better, since the problems persist regardless of what we might want to do. If something can fire more than once it needs to have something to inject into the event queue, and that something can't be allocated from the OS generally (memory allocation's not callable from interrupt level)


No matter what we do parrot's going to have to maintain a pool of these things. Making it a PMC means we've got garbage collection to clean up after them, which is at least something.

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)

Yep. This is a definite possibility, though it depends on how we handle things. If the only threading stuff involved is at the C level (ie the thread code doesn't execute any parrot bytecode) then it doesn't much matter.


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?

Very good questions. We have to do it, there's no choice. I left the underlying mechanism open for discussion.
--
Dan


--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to