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