On Tue, Mar 21, 2000 at 02:05:04PM +0000, [EMAIL PROTECTED] 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.
>
> 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?)
Yah, on unix everything is a file descriptor except signals (and
timers).
> 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.
I'd expect that you'd use the kernel level MsgWaitForMultipleObjectsEx()
and then check socket statuses periodically? Event implements unix
signals similarly. Instead of handling signals asynchronously, Event
receives them asyncronously (process_sighandler) but checks whether they
have been received periodically (pe_signal_asynccheck). Note how
pe_signal_asynccheck is called in c/queue.c. Will the same style work
for sockets?
> 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.
At worst, Event can fork threads to wait on sockets and communicate back
to the main Event thread with semaphores (or whatever). Ugh.
> 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...)
Eh? I'd say *kernel* *objects* are the most important.
--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank
