Gabe Schaffer <[EMAIL PROTECTED]> wrote: > Yes, there has to be a separate thread to get signals, and each thread > needs its own event queue, but why does the process have a global > event_queue? I suppose there are generic events that could be handled > just by the next thread to call check_events, but that isn't what this > sounds like.
It's mainly intended for broadcasts and timers. POSIX signals are weird and more or less broken from platform to platform. The only reliable way to get at them is to block the desired signal in all but one thread. This signal gets converted to a global event and from there it can be put into specifc threads if they have installed signal handlers for that signal. But as said the existing code is experimental and is likely to change a lot. > I don't see why there needs to be a separate thread to listen for IOs > to finish. Can't that be the same thread that listens for signals? That's the plan yes. AIO completion can be delivered as a signal. > OK, I think I understand why...the event thread is in a loop waiting > for somebody to tell it that there's an event in the global event > queue...which is really the part I don't get yet. Well, the event thread is handling timer events on behalf of an interpreter. [ long win32 proposal ] I've to read through that some more times. Do you alread have ideas for a common API, or where to split the existing threads.c into platform and common code? > GNS leo
