[threadpool] draft n2276 - interrupting tasks
Hello, 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? 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. boost.threadpool in the boost vault implements somthing like: task< R > threadpool::submit(...); template< typename R > class task { ... // interrupt task and return immediatly void interrupt(); // interrupt task and wait till it's finished void interrupt_and_wait(); // interrupt task and wait a certain time till it's finished or timeout template< typename TimeDuration > void interrupt_and_wait( TimeDuration const& td); // interrupt task and wait to a specific system time till it's finished or timeout void interrupt_and_wait( system_time const& st); bool interrupt_requested(); R get() { return impl_fut_->get(); } bool ready() const { return impl_fut_->ready(); } bool has_value() const; bool has_exception() const; }; Following Herb Sutters sugestions the submited task must be cooperative (contain interruption_point). What do you think? Should/Could it be added to the draft? regards, Oliver { return impl_fut_->has_exception(); }
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
participants (2)
-
Anthony Williams -
k-oli＠gmx.de