search

cplusplus / sender-receiver

Issues list for P2300
Apache License 2.0
20 stars 3 forks source link

What forward progress guarantee should the run_loop provide? #130

Open ericniebler opened 10 months ago

ericniebler commented 10 months ago

Issue by ericniebler Thursday Nov 25, 2021 at 01:37 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/281

It presently doesn't specify a forward progress guarantee.

ericniebler commented 10 months ago

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 commented 3 months ago

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.