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