From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-14 09:56:02
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk