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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-03-24 16:42:36

On Saturday 24 March 2007 12:52 pm, Braddock Gaskill wrote:
> 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.

I had similar misgivings about future::cancel() when splitting promise out 
of future, as mine works similarly.  I suppressed those doubts at the 
time, because the alternative I saw of just having it reduce a reference 
count in the promise would require the future's destructor to do a 
cancel() to be at all useful.  That causes problems for me, because I 
don't want method requests to be cancelled just because the returned 
future was ignored and went out of scope.

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

It is out there:

http://www.comedi.org/projects/thread_safe_signals/doxygen/index.html

Unless by "out there" you mean accepted into boost, which would also be a 
reasonable definition.

-- 
Frank