Re: [boost] Review Request: future library (N2561/Williams version)

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-14 09:56:02

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 14 May 2008 08:28 am, Anthony Williams wrote:
> "vicente.botet" <vicente.botet_at_[hidden]> writes:
> > Why you don't want to provide completion callbacks? Have you another
> > proposal for completion callbacks?
>
> I don't like them because you're chaining work onto the thread that sets
> the future value, and that strikes me as dangerous.
>
> > Maybe you could open the interface and return the last callback setting.
> > This will result in a chain of responsabilities and the client must be
> > aware of that with thow potential problems: growing stack and clients
> > forgetting its responsabilities.
>
> I really don't see the need for multiple wait callbacks.
>

To add my 2 cents: in libpoet, I allow multiple completion callbacks by 
providing poet::future::connect_update() which takes a slot (from 
thread_safe_signals).  A completion callback allowed me to solve the "wait 
for multiple futures" problem which arose in my scheduler classes (which 
contain a queue of method requests, each of which must wait for a set of 
input futures before in can be executed).  The completion callback notifies a 
condition variable which the scheduler thread is waiting on so it can wake up 
and see if any method requests have become ready.

I chose signals/slots over a simple callback because I find simple callbacks 
unbearably primitive (no multiple callbacks, no automatic connection 
management).  I may be more enthusiastic about using signal/slots than most 
however.  As was mentioned earlier, It is possible to tack on a signal to a 
simple callback.  You could bundle each future with a signal and make the 
callback just invoke the signal.  However, that requires every future to have 
its own signal.  By integrating the signals/slots into the future library, 
the future and all its copies can accept slots and forward them to a single 
signal which is invoked when their promise is fulfilled or reneged.

If there are no completion callbacks, I regard at least the ability to wait on 
an arbitrary number of futures simultaneously as essential.  Something that 
provides functionality analagous to POSIX select() on a set of file 
descriptors.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIKu915vihyNWuA4URAiCjAKDUNsClBfsktvFC+cShsEWe3rA62wCdEICb
qkv7JM8XovbY+bn/cvpaUEw=
=2KGe
-----END PGP SIGNATURE-----