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_thread provides the part of std::jthread the 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 raw std::thread in the engine would fix this instance and leave the gap open.
  • The callable keeps its std::stop_token signature. 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::thread uses, which are portable already.

Emacs 29.3 (Org mode 9.6.15)