Story: Hotfix: the workflow deadline watch uses a thread Apple's libc++ lacks
Table of Contents
This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
Both macOS legs are red at one declaration:
projects/ores.workflow/core/include/ores.workflow.core/service/workflow_engine.hpp:383:10: error: no type named 'jthread' in namespace 'std'; did you mean 'thread'?
Apple's libc++ has no @c std::jthread. This story first recorded that the stop token and the stop source were available, because the engine's lambda took one and the compiler did not complain: it did not complain because the declaration holding the lambda had already failed. The build after the fix named both as missing too, and the follow-up hotfix implements the stop state in the shim as a result.
The gap has cost a build before: caf6de734d reverted a comms thread to
std::thread on 2026-03-12 for the same reason. Reverting this one the same
way would leave the next author free to reintroduce it a third time, so the
fix is the portable type, in the component that exists for exactly that.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 26 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-09-30 |
3. Acceptance
ores.platform::concurrency::stoppable_threadprovides the part ofstd::jthreadthe estate uses: it carries a stop token to its callable, and it requests a stop and joins in its destructor.- The workflow engine uses it, and no source in the estate names
std::jthread. - The tree builds, the workflow and platform suites pass, and both macOS legs link and test.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Implement Hotfix: the workflow deadline watch uses a thread Apple's libc++ lacks | DONE | 2026-09-30 | 2026-09-30 | Add the portable stoppable thread to ores.platform, move the engine onto it, run the affected suites, and take it to a macOS verification run. |
5. Decisions
- The portable type goes in
ores.platform, whose concurrency header already says it holds "the types that stand in for a C++20 standard facility a supported standard library does not implement". A revert to rawstd::threadin the engine would fix this instance and leave the gap open. - The callable keeps its
std::stop_tokensignature. The token is the part Apple implements, so the caller's code is unchanged and the portability difference is confined to who owns the thread. - The type carries no export attribute: every member is defined in the header, and an export attribute on a header-only type is the link failure fixed earlier today in ores.workflow.api.
6. Out of scope
- The estate's remaining
std::threaduses, which are portable already.