Solarmutex Deadlock when Closing Calc which contains functions with XVolatileResult return values

[anwen]

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 at .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.