Repository navigation
Parallel scheduler namespace problems #2071
Description
The STDEXEC namespace is dependent on the definition of STDEXEC_NAMESPACE, which may be std::execution.
In __config.hpp there exists an unconditional definition of namespace std::execution::parallel_scheduler_replacement. It's unclear to me if this is intended.
In sudoku.cpp STDEXEC_NAMESPACE is locally defined as std::execution. However, this breaks when using STDEXEC_BUILD_PARALLEL_SCHEDULER , because parallel_scheduler_replacement is now built in a separate TU, which is unaware of the local namespace override. This nested namespace ends up in namespace STDEXEC in on TU and in namespace std::execution in another.
I also noticed that STDEXEC_BUILD_PARALLEL_SCHEDULER is not tested in CI, which is probably why this problem has gone unnoticed thus far.
I think the simplest solution here would be to:
- Use
STDEXECinstead ofstdand nested namespace insudoku.cpp. - Define
STDEXEC_BUILD_PARALLEL_SCHEDULERin the CI builds. - Either remove or document the unconditional
std::executionnamespace in__config.hpp.
Activity
vasama commentedon May 8, 2026
Oh, now I also noticed that many of the tests and examples fail to build when
STDEXEC_NAMESPACEisstd::execution.vasama commentedon May 9, 2026
parallel_scheduler.lib/libparallel_scheduler.acontainsquery_parallel_scheduler_backendin namespacestdexec, whilesudoku.obj/sudoku.cpp.ocontains it it in namespacestd::execution. Using MSVC, this fails to link due to the missing symbol. Using GCC and Clang, which apply a weak attribute, linking succeeds butexample.sudokucrashes at runtime due to the missing symbol, whose absence was accepted due to the weak attribute.alwaysprince05 commentedon Oct 5, 2026
The TU-mismatch part was fixed the same day this was filed:
60003095("fix sudoku example when separately compiling the parallel scheduler", May 8) removed the localSTDEXEC_NAMESPACEoverride fromsudoku.cpp.The unconditional
std::execution::parallel_scheduler_replacementforward declaration in__config.hppis still there, but it's now paired with theSTDEXEC-namespace twin under!STDEXEC_USE_MODULES(), so the remaining concern is narrower than described.The CI-coverage suggestion still stands though:
STDEXEC_BUILD_PARALLEL_SCHEDULERis a CMake option (test/CMakeLists.txt,examples/CMakeLists.txt) but no GitHub workflow sets it, so the separately-compiled scheduler still isn't exercised in CI. Happy to put up a PR adding it to one of the workflow matrices if there's interest.alwaysprince05 commentedon Oct 13, 2026
@vasama — following up on my comment above about CI coverage: I can put up a small PR that runs the separately-compiled parallel scheduler (
STDEXEC_BUILD_PARALLEL_SCHEDULER=ON, plus thetest.parallel_scheduler_replacementtarget) in one of the CI workflow matrices, so the configuration your #2104 reorganizes stays exercised going forward.Before I start: does that overlap with the CI-relevant parts of #2104, or is it fine as a separate change? Happy either way — if it fits better inside your PR, just say so and I'll leave it to you.
vasama commentedon Oct 20, 2026
If you want me to engage, then you need to as well. I'm not going to waste my time talking to your LLM.
alwaysprince05 commentedon Oct 20, 2026
Fair point, and thanks for being direct with me. I should’ve been upfront about it from the start. I still think adding STDEXEC_BUILD_PARALLEL_SCHEDULER to the CI matrices would be useful, but if you’d rather handle it yourself or leave it to the maintainers in #2104, that’s completely fine. I won’t push it further.