Q: Event Queue
Leopold Toetsch
- is the event queue the struct QUEUE with handling in tsq.c?
- and - as this is thread-safe - this seems to imply, that we goona do
event handling in the main thread which then dispatches signal events to
the appropriate thread. This seems reasoable for pthreads with POSIX
behavior. But the implementation in linux does/can direct signals to the
causing thread.
- OTOH we have per interpreter events e.g. Timer, IO completion
- Finally: how will we construct an event in a signal handler. AFAIK you
can't malloc it in a sig handler. Should we generate a pool of event
objects in main code, and then use these preconstructed objects in the
sig handler?
TIA
leo
Dan Sugalski
>got warnocked ;-)
>
>- is the event queue the struct QUEUE with handling in tsq.c?
Yep
>- and - as this is thread-safe - this seems to imply, that we goona
>do event handling in the main thread which then dispatches signal
>events to the appropriate thread. This seems reasoable for pthreads
>with POSIX behavior. But the implementation in linux does/can direct
>signals to the causing thread.
Yeah, I know. Signals are a major pain in the neck, as they're done
differently everywhere. I think it's possible to have a single
signal-handling thread on Linux, but I'm not 100% sure of that. (I
think POSIX mandates this be possible, but I'm not sure, and it
doesn't mean that's what happens anyway)
>- OTOH we have per interpreter events e.g. Timer, IO completion
>- Finally: how will we construct an event in a signal handler. AFAIK
>you can't malloc it in a sig handler. Should we generate a pool of
>event objects in main code, and then use these preconstructed
>objects in the sig handler?
A preconstructed pool's one way to do it, and I think the way we're
going to have to do it. This was partially what I was getting into
with Alan a while back, since there are all sorts of unpleasant
issues involved.
I *think* we can work with helper threads running at normal priority
by using the semaphore constructs that seem to be around--a thread
waits on the semaphore, while a signal flips the semaphore and wakes
up the thread that then injects an event into the queue. Not great,
but it's all I've got at the moment. Unfortunately it has the
disadvantage of not being able to transmit *any* information to the
waiting thread, so if we want to know which particular signal was
triggered we need one thread per signal. (Ick) We may be able to play
queue games to deliver information, but we run into the possibility
of being in multiple signal handlers simultaneously, which can be
rather problematic as they'd need to block each other. Maybe an array
of words we can do atomic increments and decrements on, one per
signal, but that's got issues too. Fooey. I *really* want real,
thread-safe, interrupt-safe queues...
Just in case I've never mentioned it, I *really* hate the half-baked
Unix interrupt system. Bleah.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk