[Libreoffice] SolarMutex usage...

[Michael Meeks]

Hi Michael,

	Good catch with this :-)

On Fri, 2011-10-21 at 12:28 +0200, Michael Stahl wrote:
> is there any authoritative documentation on when exactly the SolarMutex 
> should be locked when coming from the UI?

	So - with the gtk+ backend, it should mirror the GDK_THREADS lock that
protects the toolkit.

> i know that it must be locked on UNO API method entry in the parts of 
> the code that are not otherwise threadsafe, but i have no idea how the 
> UI stuff / VCL works.

	Luckily I have a pretty good idea of what is going on there :-) I spent
a lot of time on this locking integration in the past.

> for example, somebody has put a DBG_TESTSOLARMUTEX() assertion in 
> ImplWindowFrameProc, which can easily be triggered by just creating a 
> new Writer document, entering a letter or whatever and hitting the 
> 'Save' icon.

	Sure - that seems reasonable to me - it should be locked there.

> > #0  0x00007ffff7d6fdb1 in osl_assertFailedLine () from /data/lo/core/solver/unxlngx6/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
> > #1  0x00007ffff32cfacd in ImplDbgTestSolarMutex () at /data/lo/core/vcl/source/app/dbggui.cxx:1978
> > #2  0x00007ffff4457265 in DbgFunc (nAction=15, pParam=0x0) at /data/lo/core/tools/source/debug/debug.cxx:1301
> > #3  0x00007ffff34be129 in DbgTestSolarMutex () at /data/lo/core/solver/unxlngx6/inc/tools/debug.hxx:322
> > #4  0x00007ffff3782fe0 in ImplWindowFrameProc (pWindow=0x134b490, nEvent=2, pEvent=0x7fffffff6fd0) at /data/lo/core/vcl/source/window/winproc.cxx:2370
> > #5  0x00007fffe56641d7 in SalFrame::CallCallback (this=0x134b910, nEvent=2, pEvent=0x7fffffff6fd0) at /data/lo/core/vcl/inc/salframe.hxx:294
> > #6  0x00007fffe568e55e in GtkSalFrame::signalCrossing (pEvent=0x1e3c8e0, frame=0x134b910) at /data/lo/core/vcl/unx/gtk/window/gtkframe.cxx:2866
> > #7  0x000000337114ef33 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
..
> > #21 0x0000003363c2a2e2 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> > #22 0x000000337128cc86 in gtk_widget_show () from /usr/lib64/libgtk-x11-2.0.so.0
> > #23 0x00000033710c4f13 in gtk_dialog_run () from /usr/lib64/libgtk-x11-2.0.so.0
> > #24 0x00007fffdda123c2 in RunDialog::run() () from /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so
> > #25 0x00007fffdda192b8 in SalGtkFilePicker::execute() () from /data/lo/core/solver/unxlngx6/installation/opt/program/../program/fps_gnome.uno.so

	it should be locked down this entire call-frame. This looks like an
'easy' case - there is no main-loop running or anything complicated.

> > #46 0x00007fffe5083249 in SalDisplay::DispatchInternalEvent (this=0x779ce0) at /data/lo/core/vcl/unx/generic/app/saldisp.cxx:2160
> > #47 0x00007fffe566387a in GtkXLib::userEventFn (data=0x6fcc80) at /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:900
> > #48 0x00007fffe5663737 in call_userEventFn (data=0x6fcc80) at /data/lo/core/vcl/unx/gtk/app/gtkdata.cxx:865
> > #49 0x0000003360c44add in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
> > #50 0x0000003360c452d8 in ?? () from /lib64/libglib-2.0.so.0

	It is missing here - the call_userEventFn should have it.

	Good catch; I fixed another three missing instances and committed the
patch to feature/gtk3 - it should get merged soon (in the next few
days).

	In the meantime - patience much appreciated, and thanks for the report
- well worth leaving that assertion there for the future I think.

	Thanks,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot