k-oli@gmx.de writes:
the draft specifies that the threapool::submit() function returns a future object in order to retrieve the result of the submited task.
What about task cancelation/interruption?
In the absence of thread interruption, task interruption is tricky.
Instead returning a future the pool could return a task< R > object which contains a future< R > (access over R task< R >::get()) and interruption routines.
You could just add the interruption routines to unique_future.
Following Herb Sutters sugestions the submited task must be cooperative (contain interruption_point).
Yes.
What do you think? Should/Could it be added to the draft?
I think interruption support would be good for thread pools. Adding it to the proposal requires careful thought due to the controversial nature of thread interruption. One possibility I thought of was passing in a cancellation callback with the task. If someone tries to cancel the task, then it invokes the callback. This allows a user to write their own cancellation tests (e.g. set an atomic flag). The downside is you don't get the automatic cancellation points. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK