On Sunday 26 May 2013 22:59:55 Gaetano Mendola wrote:
On 26/05/2013 22.39, Andrey Semashev wrote:
On Sunday 26 May 2013 22:28:51 Gaetano Mendola wrote:
Hi, I saw that the destructor of ~mutex doesn't have a BOOST_VERIFY anymore on the return value of pthread_mutex_destroy. From SVN logs I can see it was removed in the commit 75882 to manage the EINTR due to some bugged POSIX implementation.
I will reintroduce the BOOST_VERIFY like this: ~mutex() {
int ret; do {
ret = pthread_mutex_destroy(&m);
} while (ret == EINTR); BOOST_VERIFY(!ret);
}
while we are at it consider the fact that for the same reason ~mutex needs to check for that EINTR return value the same should do timed_mutex.
Are you sure pthread_mutex_destroy can return EINTR? My Linux man page as well as [1] explicitly states it can't.
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_ini t.html Well you know there is no only Linux out there and some of those other POSIX implementation are not 100% POSIX complaint, see ticket #6200, returning EINTR even if the are not supposed to do.
Then if it's a bug, it should be treated as such - through conditional compilation, so that it doesn't affect valid implementations. Maybe even as a distro-specific patch applied to Boost packages built for it. IMHO, of course. Do you have a particular affected platform in mind? Is there a way to detect it in compile time? PS: The check for EINTR is missing in other places than ~mutex() and ~timed_mutex(). I found at least ~lightweight_mutex(), ~recursive_mutex(), condition_variable(), condition_variable_any(), ~condition_variable_any(), as well as Boost.Interprocess components: ~posix_recursive_mutex() and ~posix_mutex() to be affected. It seems, you pretty much can't use Boost multithreading on such a buggy platform.