From bcfd016c88f2da271fc77da608b42d2f5bd83448 Mon Sep 17 00:00:00 2001 From: Michael Stahl Date: Tue, 26 Nov 2013 12:58:31 +0100 Subject: some notes about COM threading in LO generally and winaccessibility - document general COM threading architecture in vcl README - document winaccessiblitiy locking in README - define _ATL_APARTMENT_THREADED for UAccCOM Change-Id: I7c3fd952f2cdee7d245a818bf33c477e7ea20fc2 --- winaccessibility/README | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'winaccessibility/README') diff --git a/winaccessibility/README b/winaccessibility/README index eb425e419b75..bac3681e720a 100644 --- a/winaccessibility/README +++ b/winaccessibility/README @@ -26,6 +26,22 @@ Here is one way of visualising the code / control flow VCL <-> UNO toolkit <-> UNO a11y <-> win a11y <-> COM / IAccessible2 vcl/ <-> toolkit/ <-> accessibility/ <-> winaccessibility/ <-> UAccCom/ +Threading + +It's possible that the UNO components are called from threads other +than the main thread, so they have to be synchronized. It would be nice +to put the component into an UNO apartment (and the COM components into STA) +but UNO would spawn a new thread for it so it's not possible. +The COM components also call into the same global AccObjectWinManager +as the UNO components do so both have to be synchronized in the same way. +So we use the SolarMutex for all synchronization since anything else +would be rather difficult to make work. Unfortunately there is a +pre-exising problem in vcl with Win32 Window creation and destruction +on non-main threads where a synchronous SendMessage is used while +the SolarMutex is locked that can cause deadlocks if the main thread is +waiting on the SolarMutex itself at that time and thus not handing the +Win32 message; this is easy to trigger with JunitTests but hopefully +not by actual end users. Debugging / playing with winaccessibility -- cgit