Skip to content

fix deadlock when awaiting a sender completes inline with set_stopped#2038

Merged
ericniebler merged 14 commits intoNVIDIA:mainfrom
ericniebler:fix-stdexec-task-deadlock
Apr 24, 2026
Merged

fix deadlock when awaiting a sender completes inline with set_stopped#2038
ericniebler merged 14 commits intoNVIDIA:mainfrom
ericniebler:fix-stdexec-task-deadlock

Conversation

@ericniebler
Copy link
Copy Markdown
Collaborator

fixes #2036

@ericniebler ericniebler force-pushed the fix-stdexec-task-deadlock branch from 931ff8a to b8cd4b6 Compare April 23, 2026 02:09
@mika-fischer
Copy link
Copy Markdown

@ericniebler FYI, the current changes in this PR (i.e. b8cd4b6) do fix both #2036 and #2041 here!

@ericniebler
Copy link
Copy Markdown
Collaborator Author

Hooray! Thanks for letting me know.

@ericniebler ericniebler linked an issue Apr 23, 2026 that may be closed by this pull request
@mika-fischer
Copy link
Copy Markdown

mika-fischer commented Apr 24, 2026

I want to add that the changes in this PR broke sender_to for stdexec::task when the environment has no start_scheduler, at least in MSVC. This works in main, but now gives a hard compile error:

struct void_rcvr {
    using receiver_concept = stdexec::receiver_tag;
    auto get_env() const noexcept { return stdexec::env<>{}; }
    void set_value() && noexcept {}
};
static_assert(!stdexec::sender_to<stdexec::task<void>, void_rcvr>);

Incidentally, sender_in was already broken in the main branch before these changes. This gives a hard compile error both in main and this PR:

EDIT: Ignore the last part, I misunderstood sender_in semantics.

Encode cross-thread completion in ref count
@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented Apr 24, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@ericniebler
Copy link
Copy Markdown
Collaborator Author

/ok to test f3ae543

@ericniebler
Copy link
Copy Markdown
Collaborator Author

/ok to test 23793ef

@ericniebler
Copy link
Copy Markdown
Collaborator Author

/ok to test b86e0a5

@ericniebler
Copy link
Copy Markdown
Collaborator Author

/ok to test 7dc615b

@ericniebler
Copy link
Copy Markdown
Collaborator Author

ericniebler commented Apr 24, 2026

I want to add that the changes in this PR broke sender_to for stdexec::task when the environment has no start_scheduler

i think the fact that it compiled before this pr is a bug. you'll get an error if you try to actually connect that receiver with the task. just like the on algorithm, task needs a start scheduler.

UPDATE: see for example https://godbolt.org/z/E5j9beGq1

@ericniebler ericniebler merged commit b4a598d into NVIDIA:main Apr 24, 2026
55 of 56 checks passed
@ericniebler ericniebler deleted the fix-stdexec-task-deadlock branch April 24, 2026 19:47
@mika-fischer
Copy link
Copy Markdown

mika-fischer commented Apr 25, 2026

static_assert(!stdexec::sender_to<stdexec::task<void>, void_rcvr>);

i think the fact that it compiled before this pr is a bug. you'll get an error if you try to actually connect that receiver with the task. just like the on algorithm, task needs a start scheduler.

I think you might have missed the ! in the static_assert above.

I don't say that sender_to<task<void>, void_rcvr> should be true, I'm saying it should be false, which it was in main, but now in this PR it just doesn't compile at all anymore, which seems wrong.

EDIT: See https://godbolt.org/z/M5M459jzo

@ericniebler
Copy link
Copy Markdown
Collaborator Author

Ah thanks for clarifying. I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

3 participants