summaryrefslogtreecommitdiffstats
path: root/sot
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2020-06-23 14:53:02 +0200
committerStephan Bergmann <sbergman@redhat.com>2020-06-23 16:39:58 +0200
commitba86099d3c4804cc7e0958c9a89fbdee29456ecf (patch)
tree2b8aadd65d697d1a08520daf2111f8aedcf241b9 /sot
parentinline typedef WeakSdrObjectContainerType (diff)
downloadcore-ba86099d3c4804cc7e0958c9a89fbdee29456ecf.tar.gz
core-ba86099d3c4804cc7e0958c9a89fbdee29456ecf.zip
HACK to decouple URP release calls from all other threads
Abandoned <b9ecec7c74687ed5a9470cffb7d02e0e6e83107e> "Don't call out to UNO with SolarMutex locked" documents a deadlock where a synchronous documentEventOccurred call made with SolarMutex locked evokes an asynchronous release call back (serviced on a different physical thread, but which blocks the original thread) that then wants to acquire the SolarMutex. While we usually appear to get away with wrapping those UNO calls in SolarMutexReleaser (though knowing all too well that that is nothing but a bad hack that may well cause crashes and deadlocks at least in theory), the place in SfxBaseModel::postEvent_Impl was obviously too sensitive for that hack: It did cause enough different crashes (e.g., hitting assert(pSchedulerData == pMostUrgent); in Scheduler::ProcessTaskScheduling, vcl/source/app/scheduler.cxx) and deadlocks (e.g., different threads now taking the SolarMutex and JobExecutor's mutex in framework/source/jobs/jobexecutor.cxx in different orders) to make me search for a different "fix", so I came up with this hack instead. Change-Id: Icd26926279cb86ce529edb4544a3ec0bc9a8b108 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'sot')
0 files changed, 0 insertions, 0 deletions