About CoInitializeEx

[julien2412 <serval2412@xxxxxxxx>]

Hello,

On Win10 with master sources updated today, I noticed this log:
warn:extensions.olebridge:3356:12452:extensions/source/ole/olethread.cxx:41:
CoInitializeEx failed (expectedly): Cannot change thread mode after it is
set.
warn:extensions.olebridge:3356:12452:extensions/source/ole/olethread.cxx:61:  
Thread is in a main single-threaded apartment.

To investigate about this, I first changed all calls to CoInitialize towards
CoInitializeEx  :
-
https://cgit.freedesktop.org/libreoffice/core/commit/?id=b587de60d4e6aa96238766272d94f1499b22f696
-
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c1aab4ca12f8e3b68240d064d82cf72ccb527648
(as indicated in first patch:
"As
https://docs.microsoft.com/fr-fr/windows/win32/api/objbase/nf-objbase-coinitialize?redirectedfrom=MSDN
advised.
Moreover, it'll make concurrency model explicit")

So now, I check if there's a call to CoUnInitialize for each CoInitializeEx
and I noticed this:
58  ODriver::~ODriver()
59  {
60      CoUninitialize();
61      CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED);
62  }
See
https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/ado/ADriver.cxx?r=b587de60#49

I thought about removing line 61 (the reinit with CoInitializeEx) in dtr.

Indeed if a component needs to initialize COM library, I suppose it should
be its responsability.
However, I wonder if a thread which would have already initialized COM
library could call ADO part and so would expect that when ADO finished its
job, to have COM still initialized.
But even in this case, it could be wrong since ADO dtr always uses
"COINIT_APARTMENTTHREADED" and perhaps the caller thread uses another
concurrency model.

Any thoughts here?

Julien




--
Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice