From acbe57481e0a10be287aad59201873a0799a94f0 Mon Sep 17 00:00:00 2001 From: Stephan Bergmann Date: Thu, 25 Jun 2020 09:50:34 +0200 Subject: Rephrase comment 760980b0b510acac555f0c252fbaa10a4751bded "Fix typos" had, IMO incorrectly, removed one "that" from ..., so that that asynchronous request would... Lets rephrase the original comment in a less problematic way. Change-Id: Ic13ffaad43e2777eb36425363851b53f2f641865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97087 Tested-by: Jenkins Reviewed-by: Stephan Bergmann --- binaryurp/source/bridge.cxx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/binaryurp/source/bridge.cxx b/binaryurp/source/bridge.cxx index 4a4499de0ef4..9a73a04b9039 100644 --- a/binaryurp/source/bridge.cxx +++ b/binaryurp/source/bridge.cxx @@ -977,9 +977,9 @@ void Bridge::makeReleaseCall( OUString const & oid, css::uno::TypeDescription const & type) { //HACK to decouple the processing of release calls from all other threads. Normally, sending - // the release request should use the current thread's TID (via AttachThread), so that - // asynchronous request would be processed by a physical thread that is paired with the physical - // thread processing the normal synchronous call stack (see ThreadIdHashMap in + // the release request should use the current thread's TID (via AttachThread), which would cause + // that asynchronous request to be processed by a physical thread that is paired with the + // physical thread processing the normal synchronous call stack (see ThreadIdHashMap in // cppu/source/threadpool/threadpool.hxx). However, that can lead to deadlock when a thread // illegally makes a synchronous UNO call with the SolarMutex locked (e.g., // SfxBaseModel::postEvent_Impl in sfx2/source/doc/sfxbasemodel.cxx doing documentEventOccurred -- cgit