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

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

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