Re: [boost] 2. It is unavoidable to use threads

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-13 11:31:54

On Mon, 13 Sep 2004 00:19:07 -0500, Aaron W. LaFramboise wrote

> I'm not sure I follow you here.  The limitation is specifically this:
> #define MAXIMUM_WAIT_OBJECTS 64     // Maximum number of wait objects
> That is the maximum amount of objects you can pass to
> WaitForMultipleObjectsEx().  In the case of serial ports, you only need
> one of these per port.  These are reusable, and several user-visible
> events may depend on a single system object.  Outside of the networking
> problem, which has the separate solution (APC callbacks, which as 
> far as I know, are unlimited), it is difficult for me to see how you 
> would use more than 64 of these system objects.

Lets say you have a piece of hardware and you want to monitor a bunch of
serial ports.  Let's say you have 2 timers per serial port plus the port
itself.  Your total capacity is ~21 port. Then you have a few socket
connections and things are reduced even more.  Let me put it another way -- I
know of 2 projects that have teetered on the brink of this limit.  In both
cases, it was a huge design issue...

If it turns out that it is next near impossible to solve reasonably then I'm
ok with backing off, but I hate to see us throw in the towel before we've tried...
 
> For timers specifically, I do not think there is any need to use any 
> of the Win32 timer facilities at all.  WaitForMultipleObjectsEx()
>  has a millisecond timeout parameter which hopefully is 'good 
> enough' for timing needs.  In my implementation, timers are 
> organized into a queue, the difference between now and the timer on 
> the top used for the timeout value.

That's good -- ACE uses timer queues to solve this problem as well.  What I
was getting at is that the OS facilities have to be extended or you will run
into the timer limit very quickly.

> I guess I'm thinking this will be a very rare event, rare enough 
> that a user will know for sure that they need an extra thread.  I 
> can't think of how it would happen.  The only way I can see it 
> happening is on an older system where APCs are unavailible, but 
> these tend not to have good support for things like reading from 64 
> files all at once, anyway.

I assure you the projects this occurred on where using the latest versions of
the OS.  In one case it was hardware augmentation that caused got things up to
the limit.  In the other it was sheer software complexity/connectivity.
 
> I wouldn't be opposed to a higher level multiplexor abstraction that
> builds on the core multiplexor abstraction that did spawn extra threads
> as needed, though.

That's what I think we should strive for.  

> > Well, I think there might need to be some interface here.  For example, it
> > would be nice for the multiplexor would have a pool of threads and dispatch
> > each event to execute in a thread.  The size of that pool might be '0' in
> > which case the multiplexor uses its' thread to dispatch in -- hence
> > degenerating into a single-threaded arrangement. 
> 
> I agree.  However, I think this could be designed best by having the
> core multiplexor thread-ignorant, with a separate wrapper component
> around that core doing the thread management.

Perhaps, but I don't see how even the core multiplexor can be implemented to
operate in MT environment without locking.  It could be that we can have a
locking policy that can be null in the case of single threading...

Jeff