diff options
author | Mike Kaganski <mike.kaganski@collabora.com> | 2020-05-24 09:18:10 +0200 |
---|---|---|
committer | Mike Kaganski <mike.kaganski@collabora.com> | 2020-05-24 10:28:59 +0200 |
commit | 1126515226b60630b3a0fd72c45258b230dfe8fd (patch) | |
tree | fbc7eedbd9cf2d15db850df27fcfb7217f53d990 /sax/inc | |
parent | e3ca594d63daa7e59cee1f9745015f582ab4e773 (diff) |
Try to blind-solve cppunittester hangs on Windows
... calling OleInitialize early in sal_main to initialize COM and concurrency.
Seeing intermittent hangs in main thread in CAPNDataObject::GetData calling
m_rIDataObjectOrg->GetData, and the inner stack waiting objects in the code
doing apartment switching (I forgot to save a stack to paste unfortunately),
I suspect that being related to incorrect concurrency model. OleInitialize
docs [1] mention:
Applications that use the following functionality must call OleInitialize
before calling any other function in the COM library:
* Clipboard
* Drag and Drop
* Object linking and embedding (OLE)
* In-place activation
...
Because OLE operations are not thread-safe, OleInitialize specifies the
concurrency model as single-thread apartment.
CoInitializeEx sets COINIT_MULTITHREADED by default, so possibly that might
get called somewhere before clipboard/OLE code is called. I hope that this
change would fix those hangs.
[1] https://docs.microsoft.com/en-us/windows/win32/api/ole2/nf-ole2-oleinitialize
Change-Id: I7213c9d6cb4bd0691a3ce355995157797d7db93f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94675
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Diffstat (limited to 'sax/inc')
0 files changed, 0 insertions, 0 deletions