Re: [boost] [thread] [rfc] patch to change condition_variable and mutex error checks

Subject: Re: [boost] [thread] [rfc] patch to change condition_variable and mutex error checks
From: Brett Lentz (blentz_at_[hidden])
Date: 2011-12-02 10:54:42

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/30/2011 06:21 PM, Vicente J. Botet Escriba wrote:
> Le 30/11/11 23:05, Brett Lentz a écrit :
>> On 11/30/2011 04:51 PM, Peter Dimov wrote:
>>> Brett Lentz wrote:
>>>> Patch is attached.
>>>> 
>>>> I'd like to get some comments about this patch. Does it seem 
>>>> reasonable enough to accept? Is there a better way to handle
>>>> it?
>>>> 
>>>> BOOST_VERIFY aborts on EINTR, but EINTR is usually not fatal,
>>>> it just means you need to try later.
>>> You've attached the wrong patch. Anyway, POSIX specifically 
>>> forbids pthread functions from returning EINTR.
>>> 
> I wasn't aware of this.
>> DOH!  Correct patch attached here.
>> 
>> Posix may forbid it, but that doesn't necessarily stop a broken 
>> implementation from doing it. Like the original e-mail said, this
>> was a result of an actual customer's experience in an actual
>> production situation.
> I agree that this should be managed by Boost.Thread as other 
> workarounds. As many others we have been forced to use this idiom
> since a long time. Even if the patch is not too much time consuming
> it could use conditional compilation and be included only on bad
> posix implementations.
>> While I'd like to see the patch accepted, it would be equally
>> valid to just say that it's not a problem boost should be
>> solving, and that I need to file a bug with the OS vendor that
>> they shouldn't be violating POSIX like this. ;-)
> 
> Yes, please.
> 
> Best, Vicente
> 

I've created ticket #6200 for this patch.

I'm going to be investigating the upstream pthread library to see if I
can find out whether they've addressed the issue. However, I do think
that this patch has some value in protecting downstream consumers of
Boost from a broken threading library.

This means that any downstream consumer's effort is spent dealing with
something other than a known (POSIX violating) bug. To me, that's a win.

- -- 

- ---Brett.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO2PTCAAoJEEAzW/nB31+3L/EIAOwU2n7g+/VZlsNJFYX25VvI
0xc3mlCXTGBBuRBqdCe2JSRbcc47069EW3qDt2Mn5T1x8oUkoGoOe+aEGlzgdVE6
YYCwax0NBjnk4BVUvq1LGyM1PLAd4t47Lf2F0mxQ8miC058Jj3k3/DQLyYHUxwr5
J4GQpkifz3cOY+0JEgNhvsNo577EUNrcbDwdRukIUkKjreayFeL6O+u5JBCAagio
9CRfPz4C4E102UIOijIQHslO4mW2+dp15Ay7+iKf0+6luXeAd/oQokQadH8HQ5Vl
hI2rrYiS4GgXZhTLHf5v//ISKAPPRny18Fc1UXq7A5mIlxwibgURSxg3Xycqq3E=
=affp
-----END PGP SIGNATURE-----