[prev in list] [next in list] [prev in thread] [next in thread]
List: boost
Subject: Re: [boost] [future] Early draft of wait for multiple futures
From: Frank Mori Hess <fmhess () speakeasy ! net>
Date: 2008-05-31 0:37:35
Message-ID: 200805302037.35981.fmhess () speakeasy ! net
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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)?
[Attachment #5 (application/pgp-signature)]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic