About continues_on
, when_all
, then
and issues with Domains
#1450
DavidElesTheFox
started this conversation in
General
Replies: 1 comment 3 replies
-
thank you for raising these issues. it has brought my attention to the fact that stdexec's handling of the common domain requirement is not in conformance with the c++26 working draft. the following PR should help: #1451 after i fix the bugs we can properly discuss whether the current behavior makes sense or not. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Motivation
I was playing around different schedulers and creating senders. I was ending up in a situation where I wanted to join two senders where one was a kind of background task(coroutine). I ended up basically with a simple
when_all
expression:Devil lives in the details
How the background task looks like is a bit tricky. I mean, I need to schedule there a new sender. So, I tried to embed there the task:
My other sender was a simple
just
callSo, my intention was to read the
scheduler
from the environment and start there the background sender (calleddependency
).And it worked well when the dependency was a a simple coroutine or another sender. Here is a working example
The interesting things
I've started to play around different schedulers and I find that sometimes it works and sometimes it doesn't. And of course it was not clear the why:
starts_on
First, I thought I'm using
starts_on
when the first sender is creating. It worked fine, no issues.(see here)
continues_on
Then I tried to say not start on but using the
continues_on
API call. So, simulating that let's run the source where it was scheduled, then continue the things on 'my' scheduler.And it blown up during an
async_wait
call. The error message was about not common domains. (see the example hereThe why
After finding this documentation about customizing senders and browsing the implementations, I think I understand the issue.
I'm just pasting here the code, to explain my current understanding (having some baseline to the conversation :))
But first some terminology sync:
And back to the code:
start_point
environment is a so called dependent environment. While it is not clear yet. Its domain is the local-pool.bg_task
: useslet_value
. It preserve the original domain(scheduler), so its domain is coming from thesync_wait
.And this is an issue, while these domains are really not common.
Comparing this with
starts_on
:start_point
: it uses also alet_value
so it also preserves the domain when thewhen_all
is called.bg_task
is the same.And it works, because the two senders domain are the same.
The discussion
Maybe it is all about learning and when the documentations/examples gonna be more in the final state it won't be an issue anymore. But right now from first look it was really surprising and the error message looked not related to the change and I think it's not gonna be change by documentation.
I was thinking a lot what's the source of the confusion and what I realized:
When you read the code you can see
continues_on(a_sender, scheduler)
. Because one does not see 'What?' is gonna continues on the given scheduler, it is easy to interpret it as astarts_on
. I think it is because all the other cases the Object is the parameter of the function (starts_on(where, what)
,when_all(what, what)
,then(what)
. But here the Object is not the parameter, because what is continuing is coming in the next operation (continues_on(who, where) | then(what)
).about the origin:
transfer
I've seen that the function was recently renamed from
transfer
tocontinues_on
. Without the intention to rename it again to transfer, It is a fact that in case of transfer the Object was the function parameter and I think it fits better to the other API functions. (But I believe that there were several discussions about it already).About
transfer_when_all
I've also seen the function
transfer_when_all
and it brings me to the other idea, what is the situation when you would like to continue to dosomething
onsomewhere
without knowing, what is thesomething
? So, what if there is notransfer
orcontinues_on
function, but onlytransfer_when_all
(I.e.: Finish your things and bring me to that context) andtransfer_then
(I want to continue on this scheduler and execute that) functions?Leave it as it is
And of course there is the option to leave it as it is and the documentation will make it clear. But my thoughts on it that people are reading code first and that should be clear as far as it is possible and then comes the documentation. But, I know naming is the hardest thing and maybe the current one is the less confusing from another perspective.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions