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