From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-24 12:52:34
On Sat, 24 Mar 2007 11:49:23 -0400, Frank Mori Hess wrote:
> I don't really see the point of bringing promise into this though. Is it
> just because your add_callback is a member of promise and not future
Well, only a promise can set_exception(), and I could imagine wanting a
scheduler to do that (f.set_exception(resource_unavailable()), etc). I also
only have set_cancelation_handler() attached to promise, but that is secondary.
My promises are not yet implicitly type convertible, but I planned to add that.
> futures to observe a promise being fulfilled or reneged, and there is a
> future::cancel(). I seem to remember your future having a cancel too.
I certainly have a future::cancel(); so do Peter's C+0x proposals.
I remain a little conflicted about cancel() though...first off because it
brings set_cancelation_handler() into the picture, which is a complication.
Secondly, because it makes future<T> into a type of "task_handle". If I have
future<T>::cancel(), I start to be tempted to add
cancel() weakly implies that there is one pending "task" per future,
which is not necessarily true.
Except for that pesky "cancelation handler" callback, a cancel() call is the
same as set_exception(future_cancel()) on the promise. Thus it kind of breaks
the promise/future split.
Once thread_safe_signals is "out there", then I'd like to use it in place of
add_callback(). Both can also be used in place of
"set_cancelation_handler()", since a cancelation is basically just
Peter's proposal doesn't have an add_callback(), but it does have a
set_cancelation_handler(), if I recall.
Dockside Vision Inc