https://bugs.documentfoundation.org/show_bug.cgi?id=88824
Stephan Bergmann <sberg...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|libreoffice-b...@lists.free |sberg...@redhat.com
|desktop.org |
--- Comment #25 from Stephan Bergmann <sberg...@redhat.com> ---
The problem is as follows:
* On Windows, any FactoryLoader threads spawned from the first
OReportDefinition ctor -> OReportDefinition::init
(reportdesign/source/core/api/ReportDefinition.cxx) end up calling
WinSalInstance::CreateFrame blocking on a call to SendMessageW (which blocks
until the message has been processed, by the main thread's event loop).
* On the main thread, CreateDocument
(embeddedobj/source/commonembedding/persistence.cxx) is trying
createInstanceWithArgumentsAndContext, and if that throws an exception (because
the requested service does not support XInitialization) calls just
createInstanceWithContext.
* OReportDefinition does not support XInitialization, and thus
OSingleFactoryHelper::createInstanceWithArgumentsAndContext
(cppuhelper/source/factory.cxx), before throwing the exception, disposes the
OReportDefinition instance.
* OReportDefinition::dispose (on the main thread) tries to join any
FactoryLoader threads (blocked waiting on the main thread's event loop).
The immediate hotfix thus appears to be to make OReportDefinition trivially
support XInitialization (by just ignoring any call to initialize).
However, that would not really help, as shortly after that first
OReportDefinition instance gets synchronously disposed on the main thread when
dbaui::OApplicationController::openElementWithArguments's case E_FORM
(dbaccess/source/ui/app/AppController.cxx) is done with its xDefinition
(referencing a dbaccess::ODocumentDefinition ultimately holding the
OReportDefinition), so would still block.
The best fix would therefore be to get rid of the FactoryLoader threads. It is
unclear what they are supposed to be good for. They got introduced with
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=bda7e683aeb1e4f64967a0cb2bd69c9152c44037>
"CWS-TOOLING: integrate CWS dba32b" which is the cumulation of more than 300
individual commits, without any hint of a rationale.
As FactoryLoader::execute effectively just calls loadComponentFromURL with
"Hidden" set to true, immediately followed by a dispose of the obtained
component, and does not synchronize with any other thread for communication, it
looks like it is either unnecessary, or an alleged performance optimization
(e.g., causing things to be preloaded), or a race condition.
Assuming it is an alleged performance optimization, the solution is thus to
just remove the FactoryLoader threads. Not being able to reliably join a
spawned thread (so it can wreak havoc during exit) is deemed worse than a
potential performance degradation.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
