Re: The new Arthur "two queues" Jackson* implentation of signals

[Robert Collins <rbcollins at cygwin dot com>]

On Sat, 2003-08-23 at 06:17, Christopher Faylor wrote:
> On Sat, Aug 23, 2003 at 06:08:20AM +1000, Robert Collins wrote:
> >On Sat, 2003-08-23 at 02:05, Christopher Faylor wrote:
> >>However, I do have this vague feeling that this implementation might be
> >>useful for signals/threads so I'll keep it, at least for now.
> >
> >I suspect we'll need one queue for the process, and then one queue per
> >thread.  Signals masked out of some threads but not the process may be
> >delivered to the process queue, and from there to the first thread that
> >hasn't masked that signal out.
> 
> Yes, this is what I was thinking.  This gets into problems, though,
> since if you link threads this way, then the number of threads becomes
> limited to what you can wait for with WaitForMultipleObjects.  That's a
> really low limit.

Well, you could decouple the queue handling and notification mechanisms:
(Note: I haven't read the signal code recently, take this section as
handwaving and use appopriately :}) Use one event for the process queue,
and one event for 'thread queues'. When you're triggered, step through
the thread queues, with no timeout, which at a step rate of 64 will get
you across most appplications thread lists in one call.

Or, if you where referring to locking the structures that record the
next event, to prevent races, Interlocked writea, synchronised read /
interlocked pops lists and circular buffers are well studied...

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part