stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Thu, 06 Sep 2012 13:16:20 GMT
On 09/05/12 23:51, Martin Sebor wrote:
> On 09/05/2012 09:03 PM, Stefan Teleman wrote:
>> [...]
>> Agreed.
>> But: if the choice is between an implementation which [1] breaks ABI
>> and [2] performs 20% worse -- even in contrived test cases -- than
>> another implementation [2] which doesn't break ABI, and performs
>> better than the first one,  why would we even consider the first one?
> Breaking the ABI is not an option (unless we rev the version).
> But I'm not sure I understand what you think breaks the ABI.

I think Stefan is referring to adding a mutex member variable to the facet in question and
breaking binary compatibility. If that is the case I have confused things when I suggested
exactly that, earlier. A cursory read through the __rw_facet source shows that inherits from
__rw_synchronized in MT builds, therefore each facet carries its own mutex member.


> We don't need to add a new mutex -- we can use the __rw_facet
> member for the locking. Or did you mean something else?
> Martin
>> --Stefan

And now I see with eye serene
The very pulse of the machine.

View raw message