Story for non-blocking submission about stdexec

[LeeHowes]

Non-blocking means what, though? Can we split this:

1. The forward progress guarantee under which it is safe to call the function. (so we can say if it safe to enqueue from a weak agent).
2. Whether the value is guaranteed to be ready by the time the caller returns.

We can't really say whether the value is guaranteed to not be ready. If it's safe to call on the agent, but might call it inline, what is that definitionally? It's more of a cost question than a correctness guarantee at that point.

[mjgarland]

We need a good answer to the Networking TS requirement for executors that don't block when they submit.

What is minimally required for a good answer? Is it enough, for example, to be able to check whether start_detached, and by implication also execute, guarantees not to block the calling thread?

[brycelelbach]

During the 2021-06-30 meeting, our thinking is that we introduce a way to ask a sender whether calling start_detached or start on it will block, or a way to ask if execute will block.

@griwes thinks we need:

• A sender query that asks whether start_detached blocks.
• A sender query that asks whether ensure_started blocks.
• A scheduler query that asks whether execute blocks.

My take is that we should have a query for whether start blocks.

@LeeHowes and @mjgarland point out that to solve this issue, we only need a scheduler query that asks whether execute blocks.

@griwes thinks it may be simpler for now to just ass a scheduler query that just asks about execute.

@griwes and @mjgarland suggest that perhaps this query should go in this_thread.

After group persuasion, I have been convinced to defer consideration of a query for blocking of things like start until R2, and settle for just a query for whether execute blocks. This retains the capabilities that P0443 had.

@griwes and I suggest that perhaps we should make this a single query that is parameterized on the operation or things.