Unspecified order of std::jthread stop callbacks on request_stop()

Question

Unspecified order of std::jthread stop callbacks on request_stop()
When a std::jthread registers multiple stop callbacks via std::stop_token::register_callback, the C++20 standard does not specify the order in which those callbacks are invoked when request_stop() is called.
Additionally, the standard does not mandate whether the callbacks execute in the thread that calls request_stop() or in separate, implementation‑defined threads. Many compilers run callbacks in the requesting thread, but this is not guaranteed.
Because the order and execution context are implementation‑dependent, developers cannot rely on a deterministic cleanup sequence when multiple callbacks are registered; this may cause race conditions or deadlocks if callbacks perform blocking operations.

In what order are multiple stop callbacks invoked when request_stop() is called?
Does request_stop() block until all registered callbacks have completed?
Are stop callbacks executed in the thread that initiates cancellation, or are they dispatched to separate threads?

Tasadduq Burney · Answer

Answer
The C++20 standard does not specify the order in which multiple std::stop_callback objects are invoked when request_stop() is called, nor does it guarantee that the callbacks run on any particular thread. However, the standard does require that the callbacks are invoked synchronously on the thread that calls request_stop(). Therefore, request_stop() will not return until every registered callback has finished (unless a callback throws, which causes std::terminate).
Confirmed facts (per the C++20 standard)

The invocation order of stop callbacks is unspecified; it may differ between implementations, standard library versions, or even between successive calls on the same program.
request_stop() performs the callbacks synchronously in the thread that invoked it; no additional threads are created for this purpose.
Because the callbacks are executed synchronously, request_stop() blocks until all callbacks have completed (or until one throws, triggering std::terminate).

Likely explanation (typical implementations)

Many standard library implementations (libstdc++, libc++, MSVC) invoke the callbacks in the reverse order of registration, but this behavior is not guaranteed by the standard and should not be relied upon.
If a callback performs a blocking operation, request_stop() will appear to block for the duration of that operation because it waits for the callback to return.

Steps to verify on your platform

Create a test program that registers three (or more) stop callbacks, each appending a unique identifier to a shared std::vector.
Call request_stop() on the associated std::jthread, then join() the thread.
Print the contents of the vector to observe the order in which the callbacks were executed.
Repeat the test with different compilers or standard library implementations to see whether the order changes.

Unspecified order of std::jthread stop callbacks on request_stop()