forked from amazingfate/loongoffice
f3251c3185
Lets assume that "volatile" was (confusedly) meant to address multi-threading
races (rather than signal handler races), but all access to the
LifeTimeManager::m_nAccessCount and LifeTimeManager::m_nLongLastingCallCount
members is apparently covered by LifeTimeManager::m_aAccessMutex anyway: They
are accessed in
* LifeTimeManager::impl_registerApiCall
* LifeTimeManager::impl_unregisterApiCall
* CloseableLifeTimeManager::g_close_isNeedToCancelLongLastingCalls
where in the latter access is covered by a corresponding
LifeTimeManager::m_aAccessMutex guard. And calls to the former are made from
* CloseableLifeTimeManager::g_close_endTryClose
* CloseableLifeTimeManager::g_close_startTryClose
* CloseableLifeTimeManager::g_close_endTryClose_doClose
* LifeTimeGuard::~LifeTimeGuard
* LifeTimeGuard::startApiCall
where all but the last have the calls covered by a corresponding
LifeTimeManager::m_aAccessMutex guard. And all calls to
LifeTimeGuard::startApiCall are made from
* chart2/source/model/main/ChartModel.cxx
* chart2/source/model/main/ChartModel_Persistence.cxx
following a pattern of
LifeTimeGuard aGuard(m_aLifeTimeManager);
if(!aGuard.startApiCall()) ...
where the LifeTimeGuard ctor will lock the corresponding
LifeTimeManager::m_aAccessMutex.
(There are further volatile members in LifeTimeManager and
CloseableLifeTimeManager of type bool, which are probably equally confused. But
lets leave those for another clean-up. These sal_Int32 volatile members started
to cause -Werror=volatile (like "error: '++' expression of 'volatile'-qualified
type is deprecated") with recent GCC 10 trunk in C++20 mode.)
Change-Id: I3d15caba151d697344ce30e90298abd6028d40d5
Reviewed-on: https://gerrit.libreoffice.org/79022
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>