From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-30 20:37:35
On Friday 30 May 2008 20:21, Frank Mori Hess wrote:
> On Friday 30 May 2008 17:41, Giovanni Piero Deretta wrote:
> > Hum, I think that boost already has such a dispatcher: it is called
> > asio::io_service ;).
> > IMHO futures wait sets should be used to wait for very few events. If
> > the number of events grows significantly, it is probably a sign that
> > the application would be better redesigned as an event driven state
> > machine. I do not think it is worth optimizing futures for large N.
> That's essentially where I started. To do an event driven design
> requires the ability to generate an event when a future completes. That
> means a completion callback as part of the future's public interface. A
> completion callback has been resisted as too dangerous, and waits on
> groups of futures offered as a safer alternative. Therefore, I'm trying
> to insist the wait functionality be sufficient to build a decent
> scheduler on.
What if we specifically support asio for handling future completion events?
That is, the future lets you register an asio::io_service along with a
completion handler, and the promise just posts the completion handler to
the io_service when it is fulfilled. Then the completion handler won't
actually get run in the promise-fulfilling thread. Would that be safe
enough and is it sensible (I don't know asio very well)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk