Boost logo

Boost :

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-13 06:52:10

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


> 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_at_[hidden]>

Boost list run by bdawes at, gregod at, cpdaniel at, john at