diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2020-06-23 14:53:02 +0200 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2020-06-23 16:39:58 +0200 |
commit | ba86099d3c4804cc7e0958c9a89fbdee29456ecf (patch) | |
tree | 2b8aadd65d697d1a08520daf2111f8aedcf241b9 /comphelper | |
parent | 4c7a3286fd05b1939acb45b2333c1ee927b0d4db (diff) |
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 'comphelper')
0 files changed, 0 insertions, 0 deletions