Cancelling pipeline internally (i.e. from insideone of its filters) is always possible with
The interface to cancel a pipeline externally is not yet added; it will be done later and we will announce it. The interface most probably will allow you to pass a reference to an instance of tbb::task_group_context into pipeline.run(), and another thread in your application could call cancel_group_execution() for that instance to cancel (the rest of) pipeline execution.
Thanks for the pointer. I think using
will be sufficient for my use case. I didn't realize this was possible.
Also, I'm not running the pipeline inside another algorithm so that should not
pose a problem.
and returns NULL. This seems to work correctly when the number of tokens is small, but if I make the number of tokens larger the code hangs in
#0 0xffffe405 in __kernel_vsyscall ()
#1 0xf7dfd0ac in sched_yield () from /lib/tls/libc.so.6
#2 0xf7f99118 in tbb::internal::CustomScheduler<:INTERNAL::INTELSCHEDULERTRAITS>::wait_for_all ()
#3 0xf7f92a5f in tbb::pipeline::run () from ...
This happens only with more than one thread running and is very repeatable on different machines and with different numbers of threads. I'll try and post a simple
representative example shortly. Any thoughts?
We thought more of it. Actually, my advice of using task::self() to cancel the execution was not good.
The proper solution depends on the effect you want to achieve. In case of the interrupt, you might want either 1) stop producing new jobs, or 2) cancel all jobs in the fly, or 3) suspend jobs between pipeline stages and resume later. The first case is simple to do and you do not need cancellation for that; you just return NULL from the input stage. The third case is the most complex, it is impossible now, and I'm afraid it will remain impossible. For the second case, cancellation should work; but unlike I thought before, the pipeline implementation should be improved to support cancellation, even internally initiated.
I apologize for confusing you. Definitely we will work on supporting cancellation (as in case 2) for tbb::pipeline. For now, your only resort is the case 1), when you return NULL from the input stage but have to wait for the jobs already started to fly through the pipeline.