Re: [boost] BOOST_THREAD_HAS_EINTR_BUG...

Vinícius dos Santos Oliveira wrote:

Em sex., 26 de abr. de 2024 às 13:51, David Bien via Boost escreveu:

...

Under Linux when BOOST_THREAD_HAS_EINTR_BUG is defined we SIGABRT at this:

~mutex() { BOOST_VERIFY(!posix::pthread_mutex_destroy(&m)); }

What is the return value of pthread_mutex_destroy here?

How is the code for BOOST_THREAD_HAS_NO_EINTR_BUG? Are UNIX signals being involved?

It's used here: https://github.com/boostorg/thread/blob/aec18d337f41d8e3081ee65f5cf3b5090179... Basically, the relevant code is: #ifdef BOOST_THREAD_HAS_EINTR_BUG BOOST_FORCEINLINE BOOST_THREAD_DISABLE_THREAD_SAFETY_ANALYSIS int pthread_mutex_destroy(pthread_mutex_t* m) { int ret; do { ret = ::pthread_mutex_destroy(m); } while (ret == EINTR); return ret; } #else BOOST_FORCEINLINE BOOST_THREAD_DISABLE_THREAD_SAFETY_ANALYSIS int pthread_mutex_destroy(pthread_mutex_t* m) { return ::pthread_mutex_destroy(m); } #endif The only scenario in which the former can return nonzero when the latter doesn't would be if it returns EINTR, and then tries to destroy the mutex again, and then get EINVAL because the mutex has already been destroyed. But this doesn't make sense because in this case the other function would have returned EINTR, which is also nonzero, so it should also fail the VERIFY. So I'm at a loss here. More printf debugging (printing the return values in both cases) is needed.