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