sequence: missing transition (?)

Aberta

#2,344 aberta em 16/10/2026 4 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade: 5/5
Tempo estimado: Mais de uma semana
Facilidade para iniciantes: 12/100

Tipo de issue: Bug
Clareza: Precisa de esclarecimento
Status de atividade: Ativa
Stack de tecnologia: cpp
Domínio: backend

Direção de pesquisa

Start with __sequence.hpp around line 255, where __state_->__start_next() runs inside the previous sender's completion, and with the static_assert on __completion_domain_of_t in the reproducer. The open question is semantic: whether exec::sequence should accept senders from incompatible domains, insert transitions such as continues_on, or reject them. Done means a maintainer decision on that behavior, followed by a fix and a test covering the CUDA-to-thread-pool case.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

We think exec::sequence should either inject transitions, or reject completely when senders are incompatible.

Consider the following code.

#include "stdexec/execution.hpp"
#include "nvexec/stream_context.cuh"
#include "exec/static_thread_pool.hpp"

struct Functor {
    //! Seems like clang requires the @c __host__ annotation, otherwise it does not compile.
    __device__ __host__ void operator()() const noexcept {}
};

int main() {
    nvexec::stream_context stream_ctx{};
    exec::static_thread_pool pool{1};

    auto sndr = exec::sequence(
        stdexec::schedule(stream_ctx.get_scheduler()) | stdexec::then(Functor{}),
        stdexec::schedule(pool.get_scheduler()) | stdexec::then(Functor{}));

    static_assert(std::same_as<
        stdexec::__completion_domain_of_t<stdexec::set_value_t, decltype(sndr), stdexec::env<>>,
        experimental::execution::_pool_::_static_thread_pool::domain>);

    stdexec::sync_wait(std::move(sndr));
}

The stream_ctx scheduler is never told that it should "come back" to the CPU side, hence the runtime issue pasted hereinbelow (with a Docker reproducer).

What happens in this very case is that the sequence receiver (trivially copyable) passed to the nvexec machinery points to a pure CPU __state_ variable, so there is no chance that __state_->__start_next() can succeed when run on the GPU.

This is because the nvexec scheduler isn't a CPU-compatible one, it needs to be told when to come back on the CPU.

This could be mitigated by verifying if the nvexec domain is "incompatible" with the domain customizing exec::sequence (in this case the static thread pool domain), in which case the above code could be simply rejected, end of the story.

But we feel like there is a more insidious issue with the semantics of exec::sequence. Our current understanding is that the next sender is connected from within the completion context of the previous sender. This makes it quite clear that the nvexec case cannot work.

Consider the following hypothetical snippet: is it supposed to work for any schd_A/schd_B combination?

stdexec::sync_wait(exec::sequence(
    stdexec::schedule(schd_A) | stdexec::then(...),
    stdexec::schedule(schd_B) | stdexec::then(...));

If the answer is yes, how can we make it work?

Should we introduce transitions represented by continues_on and schedule_from, or
Should we wrap problematic senders in stdexec::affine or something?
Anything else...

Joint work with @maartenarnst.

CUDA Exception: Warp MMU Fault
The exception was triggered at PC 0x76a00b2a7f20  stdexec::__seq::__rcvr1<stdexec::__sync_wait::__receiver<>, stdexec::__sched_env<nv::execution::_strm::stream_scheduler, stdexec::__env::__fwd<stdexec::__sync_wait::__env const&> > >::set_value()  (__sequence.hpp:255)

Thread 1 "test_sequence" received signal CUDA_EXCEPTION_30, Warp MMU Fault.
[Switching focus to CUDA kernel 0, grid 2, block (0,0,0), thread (0,0,0), device 0, sm 0, warp 1, lane 0]
0x000076a00b2a7f30 in stdexec::__seq::__rcvr1<stdexec::__sync_wait::__receiver<>, stdexec::__sched_env<nv::execution::_strm::stream_scheduler, stdexec::__env::__fwd<stdexec::__sync_wait::__env const&> > >::set_value() (this=0x76a01ffffda0)
    at /tmp/stdexec-792e1342f8c983e205d899f840038d6d57fc9bd1/include/stdexec/__detail/__sequence.hpp:255
255	        __state_->__start_next();
(cuda-gdb) A debugging session is active.

	Inferior 1 [process 101] will be killed.

The Dockerfile to reproduce the failure (click to expand).

ARG CUDA_VERSION=13.4.1
ARG UBUNTU=ubuntu26.04

FROM nvidia/cuda:${CUDA_VERSION}-devel-${UBUNTU}

ENV DEBIAN_FRONTEND=noninteractive

RUN apt update && apt install -y --no-install-recommends \
        ca-certificates curl wget \
        git \
        gnupg \
        lsb-release \
        software-properties-common \
        make cmake \
    && rm -rf /var/lib/apt/lists/*

ARG CLANG_VERSION=23

RUN wget -qO /tmp/llvm.sh https://apt.llvm.org/llvm.sh \
    && chmod +x /tmp/llvm.sh \
    && /tmp/llvm.sh ${CLANG_VERSION} \
    && rm /tmp/llvm.sh

ARG CMAKE_PACKAGE_MANAGER_VERSION=0.43.1

ADD https://github.com/cpm-cmake/CPM.cmake/releases/download/v${CMAKE_PACKAGE_MANAGER_VERSION}/CPM.cmake \
    /opt/cpm-${CMAKE_PACKAGE_MANAGER_VERSION}/

ARG STDEXEC_SHA=792e1342f8c983e205d899f840038d6d57fc9bd1

ADD https://github.com/NVIDIA/stdexec/archive/${STDEXEC_SHA}.tar.gz /tmp/

RUN cd /tmp && tar -xzf ${STDEXEC_SHA}.tar.gz

WORKDIR /tmp/

COPY <<EOF CMakeLists.txt
cmake_minimum_required(VERSION 4.0.0 FATAL_ERROR)

project(test CXX CUDA)

include(/opt/cpm-${CMAKE_PACKAGE_MANAGER_VERSION}/CPM.cmake)

cpmaddpackage(
  NAME
    stdexec
  SOURCE_DIR
    "/tmp/stdexec-${STDEXEC_SHA}"
  OPTIONS
    "STDEXEC_BUILD_TESTS OFF"
    "STDEXEC_BUILD_EXAMPLES OFF"
    "STDEXEC_INSTALL ON"
)

find_package(CUDAToolkit REQUIRED)

add_executable(test_sequence test_sequence.cpp)
target_link_libraries(test_sequence PRIVATE stdexec CUDA::cudart)
set_source_files_properties(test_sequence.cpp PROPERTIES LANGUAGE CUDA)
EOF

COPY <<EOF test_sequence.cpp
#include "stdexec/execution.hpp"
#include "nvexec/stream_context.cuh"
#include "exec/static_thread_pool.hpp"

struct Functor {
    //! Seems like clang requires the @c __host__ annotation, otherwise it does not compile.
    __device__ __host__ void operator()() const noexcept {}
};

int main() {
    nvexec::stream_context stream_ctx{};
    exec::static_thread_pool pool{1};

    auto sndr = exec::sequence(
        stdexec::schedule(stream_ctx.get_scheduler()) | stdexec::then(Functor{}),
        stdexec::schedule(pool.get_scheduler()) | stdexec::then(Functor{}));

    static_assert(std::same_as<
        stdexec::__completion_domain_of_t<stdexec::set_value_t, decltype(sndr), stdexec::env<>>,
        experimental::execution::_pool_::_static_thread_pool::domain>);

    stdexec::sync_wait(std::move(sndr));
}
EOF

ARG CUDA_GPU_ARCH=86

RUN cmake -S . -B build \
    -DCMAKE_CXX_COMPILER=clang++-${CLANG_VERSION} \
    -DCMAKE_CUDA_COMPILER=clang++-${CLANG_VERSION} \
    -DCMAKE_CXX_STANDARD=20 \
    -DCMAKE_CUDA_ARCHITECTURES=${CUDA_GPU_ARCH}-real \
    -DCMAKE_BUILD_TYPE=Debug

RUN cmake --build build --verbose

CMD ["cuda-gdb", "-ex=run", "build/test_sequence"]

Linguagem predominante: C++
Estrelas: 2.5k
Forks: 281
Merge médio: 1d 21h
PRs com merge (30d): 52

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

Leia a issue inteira e depois o guia de contribuição do projeto.
Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
Faça um fork do repositório e trabalhe em uma branch.
Abra um pull request que referencie o número da issue.

Mais de NVIDIA/stdexec

Irrelevant compilation of `include/._clangd_helper_file` for packaging and problematic name
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100

NVIDIA/stdexec#2345 · Aberta em 17/10/2026

Mantenedores costumam responder em até 1 dia
static_thread_pool hangs when the batch is smaller than the pool size.
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100

NVIDIA/stdexec#1751 · 3 comentários · Aberta em 11/1/2026

Mantenedores costumam responder em até 1 dia
test task can await a just_int sender without stack overflow (SEGFAULT) on ppc64le
Talvez já em andamento @junghans assumiu hoje. Aberta
- Algo errado?
Dificuldade 4/5 1-2 dias Facilidade para iniciantes 20/100

NVIDIA/stdexec#2355 · 1 comentário · Aberta em 22/10/2026

Mantenedores costumam responder em até 1 dia
Would you consider tagging v0.11.0?
Aberta
- Algo errado?
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 15/100

NVIDIA/stdexec#2342 · 2 comentários · 2 reações · Aberta em 16/10/2026

Mantenedores costumam responder em até 1 dia
timed_thread_context: destructor latency under concurrent submissions
Aberta
- Algo errado?
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 15/100

NVIDIA/stdexec#2337 · 1 comentário · Aberta em 14/10/2026

Mantenedores costumam responder em até 1 dia

Todas as issues de NVIDIA/stdexec

Issues semelhantes

rust: add fuzz targets for the readers?
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100

foxglove/mcap#1907 · 1 comentário · Aberta em 23/10/2026

Mantenedores costumam responder em até 1 dia
[feature] provide way to set core confs to ConanAPI
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100

conan-io/conan#20428 · Aberta em 23/10/2026

Mantenedores costumam responder em até 1 dia
Copying selected messages clears the selection (regression in 7.3.2, ae5d273)
Aberta
- Algo errado?
bug

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100

telegramdesktop/tdesktop#31505 · Aberta em 23/10/2026

Mantenedores costumam responder em até 1 dia
[Language Request] Bangla translation
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100

ddnet/ddnet#13035 · Aberta em 23/10/2026

Mantenedores costumam responder em até 1 dia
ll-builder shell completions omit existing lockfile commands and --locked
Talvez já em andamento @project-nju-learner assumiu hoje. Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 90/100

OpenAtom-Linyaps/linyaps#2291 · Aberta em 23/10/2026

Mantenedores costumam responder em até 1 dia

Mais issues de C++

sequence: missing transition (?)

Algo errado?

Avaliação

Direção de pesquisa

Descrição

Preparar o ambiente

Primeiros passos

Mais de NVIDIA/stdexec

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Issues semelhantes

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Receba novas issues na sua caixa de entrada