Re: [boost] [futures] untyped_promise or future<void>

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
future<T>::set_task_priority(), etc.

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
set_exception(future_cancel()).

Peter's proposal doesn't have an add_callback(), but it does have a
set_cancelation_handler(), if I recall.

Braddock Gaskill
Dockside Vision Inc