[future] Early draft of wait for multiple futures interface

View: New views
4 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

Re: [future] Early draft of wait for multiple futures interface

by Johan Torp :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Peter Dimov-5 wrote:
A future-based interface built on top of a callback interface doesn't seem
to suffer from the deficiencies you list, and neither does a message-based
interface (given an appropriately powerful and robust message-passing
framework in which to express it.)
One of my points is valid even for these two cases. The future-interface allows the promise-fulfiller to detect that all associated futures has died and that it needn't fulfill the request. That is, if we add this functionality to the promise class.

Johan

Re: [future] Early draft of wait for multiple futures interface

by Frank Mori Hess :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
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
benchmarking.  

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
run.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFISFiQ5vihyNWuA4URAn62AJ0ZrTsjJWna7KaaEluYVs/07KdbQQCfV5Rg
mKM4KaAnWdr8YOv9YY95vWc=
=5P/X
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [future] Early draft of wait for multiple futures interface

by Peter Dimov-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Johan Torp:
> One of my points is valid even for these two cases. The future-interface
> allows the promise-fulfiller to detect that all associated futures has
> died
> and that it needn't fulfill the request. That is, if we add this
> functionality to the promise class.

In principle, the callback interface could return a "task handle" instead of
void, one that can be used to cancel the task. This looks very similar to
asio, by the way.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [future] Early draft of wait for multiple futures interface

by Corrado Zoccolo :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 6/6/08, Peter Dimov <pdimov@...> wrote:

> Johan Torp:
>> One of my points is valid even for these two cases. The future-interface
>> allows the promise-fulfiller to detect that all associated futures has
>> died
>> and that it needn't fulfill the request. That is, if we add this
>> functionality to the promise class.
>
> In principle, the callback interface could return a "task handle" instead of
> void, one that can be used to cancel the task. This looks very similar to
> asio, by the way.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
__________________________________________________________________________

dott. Corrado Zoccolo                          mailto:czoccolo@...
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
The self-confidence of a warrior is not the self-confidence of the average
man. The average man seeks certainty in the eyes of the onlooker and calls
that self-confidence. The warrior seeks impeccability in his own eyes and
calls that humbleness.
                               Tales of Power - C. Castaneda
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
< Prev | 1 - 2 - 3 | Next >