RE: stop_token and freestanding…

Can stop_token be implemented without allocations, exceptions, or TLS? (cursory evaluation suggests yes)
Can stop_token be implemented using atomics as the only underlying synchronization primitive? (i.e. no mutex, no condition_variable)

This sounds plausible as a freestanding inclusion to me, though I won’t be recommending it get labeled as such for C++20.

From: Lib <lib-bounces_at_[hidden]> On Behalf Of Billy O'Neal (VC LIBS) via Lib
Sent: Monday, December 16, 2019 4:00 PM
To: lib_at_[hidden]; Feature Test Macros <sg10_at_[hidden]>
Cc: Billy O'Neal (VC LIBS) <bion_at_[hidden]>; Lewis Baker <lbaker_at_[hidden]>
Subject: [EXTERNAL] Re: [isocpp-lib] Feature-test macros for jthread/stop_token

> For C++20, we may be able to get away with using __has_include(<stop_token>)

No, __has_include is useless for feature tests. For example in C ++17 mode on our implementation that test will return true but `<stop_token>` is/will be effectively empty.

> Eg. Say we added a std::stop_token::callback_type type alias in future, would we add a __cpp_lib_stop_token_callback_type_alias feature-test macro?

For that we would increment the value.

I observe that stop_token isn’t presently required in freestanding. Can’t really come up with a reasonable implementation of stop_token that couldn’t trivially provide the CV and jthread stuff…

Billy3

From: Lib <lib-bounces_at_[hidden]<mailto:lib-bounces_at_[hidden]>> On Behalf Of Lewis Baker via Lib
Sent: Monday, December 16, 2019 1:47 PM
To: Library <lib_at_[hidden]<mailto:lib_at_[hidden]>>; Feature Test Macros <sg10_at_[hidden]<mailto:sg10_at_[hidden]>>
Cc: Lewis Baker <lbaker_at_[hidden]<mailto:lbaker_at_[hidden]>>
Subject: [isocpp-lib] Feature-test macros for jthread/stop_token

The working draft, N4842 currently has a single feature-test macro, __cpp_lib_jthread, that applies to both std::jthread and std::stop_token.
std::jthread is defined in <thread> and std::stop_token/stop_source/stop_callback are defined in <stop_token>

std::jthread interface depends on std::stop_token and so an implementation cannot provide jthread without also providing stop_token.
However, stop_token can be provided independent of jthread.

Is it possible/likely that an implementation might provide an implementation of stop_token without also providing an implementation of jthread or of the new condition_variable_any methods? E.g. a freestanding platform that wants to support stop_token for cancellation of async operations but that does not support threads.

For C++20, we may be able to get away with using __has_include(<stop_token>) to detect the existence of support for stop_token.
However, I can imagine that there might be some extensions to stop_token in future standard versions that are independent of jthread and that we would want to be able to test for these extensions.

Should we be adding a separate __cpp_lib_stop_token feature-test macro to allow testing of support for stop_token independently from jthread?
Should this be done now or deferred to a future version if/when stop_token changes?

If we were to add a __cpp_lib_stop_token now, would the existence of stop_token-taking methods to condition_variable_any be keyed off __cpp_lib_stop_token?
Or would it be keyed off __cpp_lib_jthread? Or perhaps add a more specific macro like __cpp_lib_condition_variable_any_stop_token_methods?
If we were to defer it then this would require checking both __cpp_lib_jthread and __cpp_lib_stop_token in future to differentiate between no stop_token, C++20 stop_token and C++Future stop_token.

Or would we add a finer-grained macro for whatever the particular extension was?
Eg. Say we added a std::stop_token::callback_type type alias in future, would we add a __cpp_lib_stop_token_callback_type_alias feature-test macro?


- Lewis