On Sat, 24 Mar 2007 19:29:12 +0200, Peter Dimov wrote:
In my proposed model, cancel() doesn't place an exception into the future. It's a consumer-side operation, used to indicate that the consumer is no longer interested in the outcome. set_exception( fork_canceled() ) is called by the producer if the cancel() call succeeds in canceling the task before it has finished.
This is a better behavior - I like it. It keeps the clear separation of future/promise (consumer/producer). The consumer can "request" a cancel() through the future, but it is still up to the producer to do something about it through the promise (possibly within the cancel_handler callback if desired) or ignore it. I don't see any downside - I'll change my implementation to match. The promise/future split with reference-counted promises keeps looking better and better to me. braddock