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

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-13 15:53:05

Jeff Garland wrote:
> On Mon, 13 Sep 2004 10:18:00 -0500, Aaron W. LaFramboise wrote
> 
>>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.

As I mentioned in another email, I agree that thread safety is important
for the 'register event listener' method.

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

Its my personal view that irresponsible use of threads and poorly
designed event handling are a primary cause of the general instability
that continues to be prevailent in modern software.

>>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 ;-)

Sounds perfect.

> 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?

For one thing, absolutely everyone that works with events within that
framework needs to know about your multiplexor class, even if they dont
actual need notification of low-level events.  This is unnecessary.

(There is one particular facet of my own implementation that I am
unhappy with that prevents me from seriously recommending it as a whole.
 It is present out of laziness, as I have not yet taken the time to
figure out a solution.)

Later today, I think I'm going to post a few examples of a starting
point of how I'd like a demultiplexor to look and feel.  More details
and rationale then.

Aaron W. LaFramboise