Do we still plan to integrate p2257's design for a blocking query?

[ericniebler]

Issue by ericniebler
Thursday Oct 28, 2021 at 21:00 GMT
Originally opened as NVIDIA/stdexec#225

---

http://wg21.link/p2257

[ericniebler]

Comment by kirkshoop
Thursday Nov 25, 2021 at 05:46 GMT

---

This paper is fine. I had thought of using a set of independent cpos for each option (is_blocking(), is_inline()). That covers the same set of 4 scenarios but is much simpler.

is_inline | is_blocking | scenario
false | false | thread pool
false | true | fork/join
true | false | non-blocking io
true | true | blocking io

[ericniebler]

Comment by kirkshoop
Thursday Nov 25, 2021 at 06:14 GMT

---

Same paper as #140

[ericniebler]

Comment by kirkshoop
Wednesday Dec 08, 2021 at 23:00 GMT

---

I like the phrasing in P2257. Applied the wording in P2257 to cover the modified semantics of is_inline and is_blocking:

is_blocking()

• true - a connected receiver's completion- signal operations will occur before execution::start() returns and execution of execution::start() shall block pending some condition external to the steps of the thread of execution.
• false - execution of execution::start() shall not block pending any condition external to the steps of the thread of execution and this does not prohibit a connected receiver's completion- signal operations from occurring concurrently on another thread prior to, concurrently with, or after return from execution::start();

is_inline()

• true - a connected receiver's completion- signal operations will occur on the calling thread before execution::start() returns.
• false - a connected receiver's completion-signal operations will not occur on the calling thread before execution::start() returns and this does not prohibit a connected receiver's completion- signal operations from occurring concurrently on another thread prior to, concurrently with, or after return from execution::start();

In both cases there is no default value - if a sender does not specialize a query, then the sender makes no guarantees at all.

[ericniebler]

Comment by lewissbaker
Saturday Dec 18, 2021 at 23:29 GMT

---

The is_blocking definition you've described here to me seems like a combination of:

• completes_synchronously - which indicates that the the call to the completion-signalling operation "happens before" the return from the call to start().
• is_blocking - which indicates that the forward-progress of the evaluation of the call to start() may depend on the forward progress of some other thread/operation.

A start() implementation that attempts to acquire a mutex, e.g. to add the op-state to a queue, might "block" even though it will not complete synchronously.

One thing that I would like to understand better is the use-case/motivation for when I would want to query is_blocking().
I can understand the use-case for completes_synchronously - I can place the op-state for such an operation on the stack rather than heap-allocate it (e.g. in submit()) or I can avoid synchronisation (e.g. in sync_wait()).

[ericniebler]

Comment by LeeHowes
Tuesday Jan 11, 2022 at 00:05 GMT

---

So completes_sychronously is a fairly clear name for an optimisable case. It is fairly well-defined.

is_blocking is a correctness check. Async_scope.spawn_now might want to check that the passed sender is !is_blocking to be reasonably startable in an async environment. Really we want that to be forward progress guarantee specific, though.

Can we pass an FP guarantee here? is_blocking(execution::parallel, sender) and for any reasonably purposes we only define this for now for parallel agents. So if a parallel agent calls start() it will complete start. A weaker agent might not be allowed to call start at all, or it is undefined and we have the option of working out how to define that correctly for other agents later.

just(3) would probably be completes_sychronously==true but is_blocking == false for all FP guarantees.

[ericniebler]

Comment by ericniebler
Friday Mar 10, 2023 at 23:55 GMT

---

It's time we start thinking hard about this issue again. Lots of related issues that a query (or two or three) might want to answer:

1. Is this operation guaranteed to make forward progress if started on a [concurrent | parallel | weakly parallel] agent?
2. Is this operation guaranteed to complete before start() returns? On this thread?
3. Is this operation guaranteed to complete on the same scheduler it started on?

Others?