Re: [boost] [thread] ~mutex and BOOST_VERIFY

Subject: Re: [boost] [thread] ~mutex and BOOST_VERIFY
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-26 17:32:58

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.