SolarMutexTryAndBuyGuard
Michael Stahl
mstahl at redhat.com
Sat Sep 27 11:44:20 PDT 2014
On 27/09/14 15:10, Miklos Vajna wrote:
> Hi Michael,
>
> On Fri, Sep 26, 2014 at 02:33:38PM -0700, Michael Stahl <mstahl at redhat.com> wrote:
>> +class SolarMutexTryAndBuyGuard
>> + : private boost::noncopyable
>> +{
>> + private:
>> + bool m_isAcquired;
>> +#if OSL_DEBUG_LEVEL > 0
>> + bool m_isChecked;
>> +#endif
>
> Isn't this exactly the situation when we should use DBG_UTIL and not
> OSL_DEBUG_LEVEL -- i.e. when the conditional part results in a different
> class layout?
in general, you are of course right.
but this all-inline guard class can only sensibly be used within a
single function, with the life time limited to a single stack frame;
this should imply that the situation where multiple compilation units
built with different OSL_DEBUG_LEVEL access the same instance with
different layout cannot happen.
on the other hand, you have a point in that inexperienced developers
could read this class and assume that all additional class members
should be guarded in this way; perhaps it would be better to change it
to DBG_UTIL just for consistency.
well, generally speaking all uses of SolarMutex::tryToAcquire() are
broken by design anyway...
on a related note, does anybody know what commit
6ea3c24201b2d4255306f6e745e242567f3bbb8c is trying to do with
SolarMutex? it clearly looks to me that the error handling paths in
vcl/unx/source/dtrans/X11_selection.cxx will not release the SolarMutex
again in case it succeeds in acquiring it, which sounds like a bad idea.
More information about the LibreOffice
mailing list