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