From: Moore, Paul
> (correct me if this is all wrong...) the event loop waits
> in pe_multiplex (which is basically implemented as
> pe_sys_multiplex).
>
This is probably just a Win32 nasty which I'm going to have to deal with
myself, but...
If I understand the code, pe_sys_multiplex basically waits in a poll/select
call until something pops up to wake it up. This implies that there is
essentially only one waiting state, which all watchers have to tie into. In
other words, if Event is sleeping on a set of filehandles, and some other
type of event comes in (an X event handled by a new type of watcher?) the
poll/select won't wake up and the event won't be serviced immediately.
Is this right? It's difficult for me to be sure, as I don't know that there
*are* any other events than poll/select-able ones in Unix. (There are
signals, I guess, but don't they interrupt system calls anyway?)
The reason I care is that while Win32 has MsgWaitForMultipleObjectsEx()
which waits for pretty much any sort of kernel object, it seems that sockets
are not kernel objects, and so need a separate wait call (select() or its
Winsock equivalent). I still have to do some more digging, but I may have an
issue here.
Is there a way for Event to cope with two separate alertable-wait type
calls? My first guess is that there isn't, as I can't see how we'd hook them
together (assuming no threads). But if that is the case, then I imagine that
an X event watcher is a non-starter, as it presumably has its own form of
event dispatcher to deal with.
For now, I'll assume it's a Win32 issue. I'll start with getting kernel
objects, and worry about sockets later. (Yes, I know this is ignoring the
most important area...)
Paul.
