Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-05 17:20:10

Hash: SHA1

On Monday 02 June 2008 04:54 am, Johan Torp wrote:
> Great, thanks for the effort. Could you post the code somewhere or mail it
> to me at johan [.] torp [at] gmail [.] com? I've been worried that an
> "ideal" future will need to hold a lot of state and becomes somewhat
> complicated.

I've committed it to the changes to libpoet cvs now. I've got future_selector
implemented, and it seems to work. I haven't completely converted my own
scheduler over to properly using it. I've done some testing, but no

My implementation has become a bit complicated, somewhat more so than
absolutely necessary. It boils down to 2 essential things I had to add to my
future implementation in order to run all user code in future-waiting
threads, and wait efficiently.

1) I added an event queue for a future, which any thread can push functors
onto, but only future-waiting threads which call
future::get/ready/has_exception will cause the functors to be popped off and

2) For efficiency, I added a signal which is emitted whenever a functor is
pushed onto a event queue. The signal publishes another event which
interested observers can push onto their own event queue. When the event is
run, it simply polls the event queue that originally emitted the signal.
This allows a future which is waiting on N dependencies to only poll the
event queues which might actually contain events, instead of having to poll
all N of them every time.
Version: GnuPG v1.4.6 (GNU/Linux)


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