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

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.