On Tue, Mar 21, 2000 at 02:05:04PM -0000, Paul Moore wrote:
> 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.
But the X event would enter the application on a file descriptor.
> 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?)
Basically unix does only have poll/select-able ones and signals
> 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.
Ak, Event does rely on there being one place where all events can be waited upon,
with the exception of signals as the will cause the poll to return anyway.
> 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).
Likewise I cannot see how you would hook these together in a way that would allow
the process to sleep while waiting for events.
Graham.
