Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:41 AM +0200 5/12/04, Leopold Toetsch wrote:
>> $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.
A persistent signal handler is some storage in the interpreter, that
associates the interrrupt number with a Sub PMC (or a chain of these).
The signal internally is a signal event. On delivery of the event (and
here we are already again in user mode) a PMC is created that holds the
event information. This PMC is then passed on to the users callback.
> ... This goes for GUI event handlers too. You can
> pre-allocate a PMC, but then you need to make sure the
[ sentence not finished but ... ]
... that you don't run out of pre-allocated PMCs. Which is likely when
you start tracking mouse move events or such. This doesn't work. You are
gonna loosing events. GUI events are coming from the GUI thread. You
can malloc an internal event structure holding the mouse coordinates,
but you can't create a PMC there.
Then the event gets put into Parrot's event system, then see below...
Signals or GUI events aren't really differing.
>>*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)
I know that. The current scheme is safe WRT these problems. A signal
originates from the signal handler, incrementing a sig_atomic_t variable
per signal. Then the signal handler returns. No allocation of anything
is in the interrupt code.
But the io_thread (which is the only one that has the signal unblocked)
gets interrupted with EINTR. Here the (malloc) allocation of the event
structure is safe, and all needed stuff is put into the event structure.
The event is now posted to the global event thread which waits on the
queue condition.
In the event thread the signal gets broadcasted to all running
interpreters. And when it's in their task_queue, its fine to create an
appropriate event PMC, if that interpreter is interested in that event.
The signal delivery is the most complex and dangerous one. And it's
already working.
You can't allocate some PMCs easily, when you don't know, where they
will go to. This has nasty issues with DOD when running multiple
threads.
> 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.
Making it a PMC in the interpreter that gets the event ... means ...
>>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.
There's always a choice. Please have a look at the current code.
leo
