What forward progress guarantee should the run_loop provide?

[ericniebler]

Issue by ericniebler
Thursday Nov 25, 2021 at 01:37 GMT
Originally opened as NVIDIA/stdexec#281

---

It presently doesn't specify a forward progress guarantee.

[ericniebler]

Comment by lewissbaker
Wednesday Dec 29, 2021 at 07:14 GMT

---

It would presumably only be able to provide either parallel progress (if the thread calling run() had a concurrent forward progress guarantee) or weak-parallel progress (if the thread calling run() has only a weak forward progress guarantee.

But we may also want to take into account the forward progress requirements of the schedule operation itself.
e.g. the reference implementation of run_loop's schedule operation acquires a mutex lock to insert the item in the queue. This means that it would generally only be safe to call start() on the schedule operation from a thread with a strong forward progress guarantee.

[lewissbaker]

I think that we probably need to require that run_loop::run() must be called from a context that has a forward progress guaranter equivalent to std::thread.

The implementation of run_loop::run() is going to need to block (eg with mutex and condvar) and so cannot safely be run on a weakly parallel context.

If that is the case then we should be able to say that run_loop's scheduler provides parallel forward progress for items scheduled to it, provided some thread is calling run().

I do not know if it makes sense to talk about an individual thread having concurrent forward progress guarantee as this guarantee is is relation to other tasks/threads and so needs to be qualified with which tasks/threads this relates to.