Improved interface for run_loop

[ericniebler]

Issue by ericniebler
Friday Nov 12, 2021 at 20:49 GMT
Originally opened as NVIDIA/stdexec#254

---

@kirkshoop says : I would prefer to replace void run() and void finish() with:

run_sender run(); // always-inline sender that will not complete until cancelled.
run_chunk_sender run_chunk(); // always-inline sender that will complete when 
                              // all the items in the queue, when the sender was 
                              // started, are all consumed. It will complete even 
                              // if the queue is not empty after consuming those 
                              // items. It will potentially complete early if cancelled.
 
stop-source-ref get_stop_source();
stop-token get_stop_token() const;
void request_stop();

[ericniebler]

Comment by griwes
Friday Nov 12, 2021 at 21:12 GMT

---

"will not complete until cancelled" - is this specifically until the sender is cancelled? Or is it until either the sender or the run_loop is cancelled? Or is it actually until either is cancelled or the queue is drained?

[ericniebler]

Comment by kirkshoop
Friday Nov 12, 2021 at 21:45 GMT

---

"will not complete until cancelled" - is this specifically until the sender is cancelled? Or is it until either the sender or the run_loop is cancelled? Or is it actually until either is cancelled or the queue is drained?

Matching the current design for 'void run()' would require that cancellation of the sender and a call to request_stop() on run_loop are the same thing. There are other viable and useful options. It might be nice to allow cancellation of the sender to not also cancel the run_loop. This allows run() to be called again and pick up where it left off.

run_chunk() is different. If the sender is cancelled it does not cancel the run_loop. Cancelling the run_loop does cancel run_chunk.

[ericniebler]

Comment by ericniebler
Wednesday Nov 17, 2021 at 17:43 GMT

---

Olivier made the valid point that semantically, finish() and request_stop() are not the same. The former doesn't cause the cancellation of any work; the run_loop keeps churning through work until the queue is empty. Presumably request_stop() will send a stop request to any in-flight work and cause any additional work in the queue to immediately complete with set_done.

I could imagine having both finish() and request_stop(), but I don't think we can drop finish() entirely.

[ericniebler]

Comment by kirkshoop
Wednesday Nov 17, 2021 at 18:10 GMT

---

request_stop() and finish() are not the same thing, yes. Cancelling the sender returned from run() is closer to finish() and could be made the same as finish(). With the upgrade that run() can be called again to do more work in cases where more work is added.