Re: Temporarily yielding SolarMutex to another thread

Am 2. Februar 2019 14:49:29 MEZ schrieb Noel Grandin <noelgrandin@gmail.com>:
> Assuming that there is no other way to accomplish this, how could it
> work
> to allow multiple child widgets to "own" the SolarMutex simultaneously?
> We
> just need one of those threads to trigger an update to something like a
> cache, and one of the other threads is likely to crash because of a
> stale
> pointer.
>
> Unless you are talking about passing some kind of permission down to
> the
> child threads, which says "this thread is allowed to also take the
> SolarMutex, even though it is already locked", which means we'd need
> another counter, and then how would that interact with
> SolarMutexReleaser.
>
> Possibly another way here is to make the parts of the child threads
> that
> currently need the SolarMutex, to get their own mutex, preferably a
> reader/writer mutex, so that multiple of them can run in parallel.

The only real fix is to get rid of SolarMutex (SM) ;-)
While that is a long term goal, the way to do this is IMHO to keep the SM in the parent thread and 
use some messaging to transfer SM work from child to parent.

Your idea is basically what the OSX VCL backend is doing: transfer work via code block passing and 
a flag to ignore SM in the main thread while working on the code block in main. Have a look at 
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/inc/osx/runinmain.hxx

In VCL we kind of do this on all platforms using different mechanisms, as all of them require to do 
GUI stuff in the main thread (unless you use threaded OpenGL), except GTK+, which also has a kind 
of SM (GDK lock), as it has to honour the platforms constraints anyway.

All the non-GUI work should use its own synchronisation primitive.