It's easy to blow this if you start monitoring any significant hardware. Start monitoring some serial ports and setting various timeouts associated with those prots and you can run into troulble easily. In fact, timers is a big problem -- you need to have a smart queing implementation that keeps the number of timers down to the bare minimum....
We will need one queue per (for events waiting) user threads. If the user uses threads, and he requests a timer event, then at the very least it should be supported to call a 'callback function' (a virtual function of a provided object) in that same thread. Possibly even we want to add support for having the callback called in a different thread. However - that is just a single event per (for events waiting) user thread. Timers will not become a problem causing us to go over the 64 limit.
It seems unlikely to me that there are many cases were the limit would be exceeded. However, in those cases, I don't think it would be a problem if the multiplex user were required to create another thread, and another multiplex. I don't think the multiplex should do this.
Well, it's ugly for the user because it's tough to predict when you are going to hit the 64. So I disagree, I'd like to see the user shielded from this issue.
My opinion too. Shielding the user from implementation specific things (that vary from Operating System to Operating System) is a Good Thing(tm). Otherwise it will be hard to write portable code :/ [more things I agree with snipped]
Well, I'll disagree with this one as well. I think it should be coupled with both thread and date_time, since you picked those two ;-)
Agreed
Here's why. I think the interface should look something like this:
class mutliplexor { public: //returns a unique event handler id template<class EventHandler, class EventMultiplexor> boost::int32_t register(EventHandler eh, EventMultiplexor em, unsigned int priority);
void remove(boost::int32_t event_handler_id);
void suspend(boost::int32_t event_handler_id);
void run_event_loop(time_duration td = time_duration(pos_infinity)); void end_event_loop(time_duration td = time_duration(pos_infinity)); };
Note that the amount of time to run the event loop is specified as a time_duration which allows things like 'pos_infinity' or run forever to be specified more cleanly than the typical interface which passes '0' meaning run forever. Now I can write code that looks like and it's perfectly clear what it means:
multiplexor m(...); //setup
while (!done) { m.run_event_loop(seconds(1)); //do other stuff like set done }
So there's the hook to date_time. BTW, for this part of date_time you only need headers -- you don't need to link the lib.
As for boost.thread, that will be needed because the mutliplexor implemenation of register will need to manage a list of event handlers and will need to be capable of dealing with the remove, suspend, and register running in different user threads. This means it will need to lock. So even if you argue away date-time I don't see how you avoid boost.thread.
My opinion too; we need to support multi-threaded user application and therefore we have to link with boost.thread. This reason is separated from the fact that I can't see how to implement this within a single thread on windows - even while considering only a few sockets so that the event limit is not the problem. -- Carlo Wood <carlo@alinoe.com>