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

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

On Mon, 13 Sep 2004 10:18:00 -0500, Aaron W. LaFramboise wrote
> Nothing irritates me more than using some third party library and
> noticing its spawning some hidden thread that I just know it doesn't
> need and isn't adding any real value.  

I couldn't agree more.

> Especially as I have implemented
> such a demultiplexor core without having sophisticated thread built-
> in support that was nonetheless very useful in conjunction with 
> multithreading, I know that if Boost's multiplexor uses threading, I 
> would not use it.

Hopefully by now my position is clear -- thread safety is required (or at
least an option) so that if the user is running MT the mutliplexor will
operate correctly in an MT environment.  Any other thread usage by the
mutliplexor would be an option controlled by the user.

Just as an aside, thread usage is totally out of control these days -- and it
creates lots of nasty issues.

> I am not opposed to any of these fancy thread management features.
> However, I do think that there needs to be fundemental, minimal
> demultiplexor core that does not have them.  These extra features 
> may be implemented by a separate module on top of the core, through 
> delegation, inheritance, or something else.

Template-based policies ;-)

> > How would one use functors to wait for the plethora of different events
> > to be handled?  Surely not as template parameter of the multiplexor class.
> > You mean as template parameter of methods of that class?  That would
> > still involve a dereference (some virtual function) in the end, somewhere
> > imho; you don't seem to gain anything from this in terms of inlining
> > (the main reason for functors I thought).  Templates do however tend
> > to cause a code bloat :/
> 
> Well, I'm not sure.  As I've mentioned in some thread, my previous
> design had a few cases on indirection.  At the very least, the use of
> indirection should be minimized.
> 
> On the other hand, I am not sure that I agree with the general form 
> of multiplexor used by ACE, or mentioned by Jeff.  In particular, I 
> do not like the monolithic multiplexor that pokes its way into every 
> module of the program.  I think a multiplexor is silent, and only 
> seen when looked for.  I also think that an 'event,' while a useful 
> notion for implementors, is not something that needs to exist tangibly.

I don't follow how my interface was monolithic.  Unlike must multiplexor
designs I've seen it didn't have nary a mention of sockets, file i/o, etc.  It
wasn't a singleton, either. Of course, it's just an idea -- I haven't built it
-- perhaps it can't be done that way.  But believe me, I'd love to see some
alternate design suggestions -- I'm not locked into current current design
thinking by any means.  Any chance you are going to be able to post your design?

Jeff