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

1 files changed, 16 insertions, 0 deletions

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