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 <[email protected]> On Behalf Of Billy O'Neal (VC LIBS) via Lib Sent: Monday, December 16, 2019 4:00 PM To: [email protected]; Feature Test Macros <[email protected]> Cc: Billy O'Neal (VC LIBS) <[email protected]>; Lewis Baker <[email protected]> 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 <[email protected]<mailto:[email protected]>> On Behalf Of Lewis Baker via Lib Sent: Monday, December 16, 2019 1:47 PM To: Library <[email protected]<mailto:[email protected]>>; Feature Test Macros <[email protected]<mailto:[email protected]>> Cc: Lewis Baker <[email protected]<mailto:[email protected]>> 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
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
