Re: Moving sp_thread_pause, sp_thread_sleep to Core

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-06-02 23:47:12

On 6/2/23 20:01, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>>>> #include <boost/smart_ptr/detail/sp_thread_pause.hpp>
>>
>> There is a better implementation in Boost.Atomic:
>>
>> https://github.com/boostorg/atomic/blob/2d45635e5b333f116030e3a779511d296c21f75f/include/boost/atomic/detail/pause.hpp
> 
> Indeed.
> 
> It's better in three ways: implementation for ARM, forceinline,
> and noexcept.
> 
> I've applied these to sp_thread_pause (thanks) and in the process
> submitted a GCC feature request
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
> 
> I've also applied the noexcept to the other two functions, which
> lead me to discover an interesting issue with sp_thread_sleep:
> nanosleep is a POSIX cancelation point, which means that it can
> "throw":
> 
> https://github.com/boostorg/core/commit/e088fb89292bb301e69f4b35ba09defb4063f338
> 
> which exposed the need for the following fix:
> 
> https://github.com/boostorg/core/commit/23ef6d35316be0dfc4e110e701f2fccdeae94eec
> 
> Just thought these observations could be of interest to people here.

Does cancelling a thread count as a C++ exception, meaning, in
particular, does it trigger std::terminate when it leaves a noexcept
function? I know they reuse stack unwinding machinery to implement
pthread_cleanup, but interacting with C++ constructs like that sounds
like a bug.

In any case, IMHO, pthread_cancel() should be banned in C++.