Thank you, Stephan and Michael. Stephan, I will explain my observations with the Doc events later. Michael, would you mind explaining more about "figuring out how to fix all that without losing the "synchronous" nature of the notification that i bet extensions depend upon"? As an extension Developer, instead of a LibreOffice developer, I have no clue of it right now, :-(
A brief summary of this discussion: My purpose is to develop a Calc extension based on LibreOffice environment. As an extension, it registers itself as a UNO component and provides some add-in functions which retrieve streaming data. This extension object builds connections via worker threads to an outside streaming data server. Everything runs well until I terminate the LibreOffice with x click: Soffice.bin/Soffice.exe are still alive after the termination process is completed and all the documents are closed. It happens when the worker threads try to update the spreadsheet using modified() function and the termination process tries to stop the worker threads. SolarMutex may be the reason of this issue. To solve the issue, I implemented two interfaces: XTerminationListener and XEventListener. The former listens to desktop.termination. The latter listens to document events. From my observation, the worker thread could be blocked within modified() forever by queryTermination() and notifyTermination(). It could also be blocked forever by some documents events, like OnPrepareViewClosing, OnPrepareUnload, OnViewClosed, OnUnload, OnUnfocus, and OnCloseApp. Interestingly, I observed that the worker thread could resume running when seeing OnModeChanged event. Currently, my workaround with the SolarMutex issue is double termination 'x'' clicks: first termination is vetoed in queryTermination() where I setup status change to avoid modified(). Then the second termination will kill all the threads and the LibreOffice process. Right now, I did double terminations manually. I am wondering if I could manipulate OnModeChanged events which may solve the issue too. Although the spreadsheet shows dynamic data with XVolatileResult return type, it does not popup save dialogue if I open an existing calc file. Michael Meeks suggested me to veto and then call XDesktop.terminate() within the code. I tried it but finally gave up because 1, the Calc extension is not a complete process and has not a main() function. 2, the worker thread is not suggested to stop and kill itself. So I am not sure where to call the XDesktop.terminate() after veto. I hope that my observations and the discussion here could help LibreOffice improve its support to multi-threads extensions, especially XVolatileResult related. Thanks, Wendi Michael Stahl-2 wrote > > On 14/08/12 16:30, Stephan Bergmann wrote: >> On 08/14/2012 03:20 PM, anwen wrote: >>> In addition, from the link >>> (http://www.openoffice.org/api/docs/common/ref/com/sun/star/sdb/OfficeDatabaseDocument.html), >>> I saw that both "OnPrepareUnload" and "OnUnload" events are >>> synchronously >>> broadcaster. Does it mean SolarMutex protection again? I really hope it >>> does >>> not. >> >> I'm not sure what that "broadcasted synchronously" column there is >> supposed to mean. > > i guess it means that the event is broadcast immediately when it occurs, > blocking the event source until it is handled. > > asynchronous document events (in SFX based apps) seem to be delayed via > SfxEventAsyncer_Impl, which creates a VCL timer that times out > immediately. > >> In general, (UNO) listener notifications must happen >> with no mutices locked. So I would hope for "it does not" too... > > so much for the theory; in practice SFX pre-dates UNO and was possibly > not designed with threading in mind, thus this is not actually what > happens; it appears that the OnUnload event originates in > SfxBaseController::dispose() (which of course locks SolarMutex > thoughout). as > > SFX_APP()->NotifyEvent( SfxEventHint(SFX_EVENT_CLOSEDOC > > and then is transmitted via SfxBroadcaster interface to > SfxBaseModel::Notify, then to SfxBaseModel::postEvent_Impl which uses > the cppu::OMultiTypeInterfaceContainerHelper member [1] of > IMPL_SfxBaseModel_DataContainer to send the event out via UNO interface > XDocumentEventListener::documentEventOccured. > > then the SfxGlobalEvents_Impl (GlobalEventBroadcaster) gets it and just > forwards it to the registered listeners. (i get the idea that the > GlobalEventBroadcaster exists mainly to allow for listening for events > at documents that are currently being loaded or created, so the client > does not have a reference to the document yet) > > figuring out how to fix all that without losing the "synchronous" nature > of the notification that i bet extensions depend upon is left as an > exercise for the reader. > > [1] in fact (to add insult to injury) SfxBaseModel has a mutex member > that is used exactly once, to initialize its > cppu::OMultiTypeInterfaceContainerHelper member. > > _______________________________________________ > LibreOffice mailing list > LibreOffice@.freedesktop > http://lists.freedesktop.org/mailman/listinfo/libreoffice > Thank you -- View this message in context: http://nabble.documentfoundation.org/Solarmutex-Deadlock-when-Closing-Calc-which-contains-functions-with-XVolatileResult-return-values-tp3998056p4001524.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
