Re: Temporarily yielding SolarMutex to another thread

On Friday 01 of February 2019, Noel Grandin wrote:
> On Fri, 1 Feb 2019 at 17:11, Luboš Luňák <l.lunak@collabora.com> wrote:
> > - Calc threading - the Interpret() call may spawn several threads to
> > compute
>
> This case smells like this functionality should be using a different mutex
> instead of the SolarMutex, then the main thread could hold some kind of
> InterpretMutex, and the child threads could acquire and release the
> SolarMutex as necessary.

 That wouldn't work. As I said, the main thread cannot release SolarMutex at 
that point, since any other thread could acquire it there. And as long as the 
main thread cannot release SolarMutex, no other thread can acquire it, not 
even the child ones. And as long as the child threads cannot own SolarMutex, 
they cannot use all kinds of LO functionality that require it, not just Calc 
code, but anywhere.

> Perhaps the calling thread should pass both an operation and a
> std::function to the clipboard thread, which the clipboard thread can post
> back to the event thread once it's done - kind of a poor mans continuation.

 We have places locking SolarMutex all over the codebase. That'd be such a 
mess to do it from places that the child thread could possibly reach. Playing 
tricks with mutexes would be a nice clean approach compared to that.

> "freed too late" ? sounds like an ownership issue, not a threading issue?

 It's roughly like this: There's SdrModel and some SdrObject instances, which 
refer to the SdrModel. Some SdrObject may get added to clipboard contents. 
Later, when it all is about to get deleted, first all SdrObject instances get 
deleted from whatever may refer to it, which includes resetting clipboard 
contents to something that no longer refers to it. And when all that is done, 
SdrModel is destroyed too.

 Except, Windows clipboard handling decided it would be fun to delay resetting 
clipboard contents, and so one SdrObject actually gets destroyed only later, 
when the clipboard code finally gets to it. SdrObject dtor refers to the no 
longer existing SdrModel, *boom*.

 The way I see it, this is clearly a fault of the Windows clipboard code.

> I'm sure it is possible to get clever with mutexes, but I suspect you'd
> just be setting yourself up for bugs that are even harder to reason about.

 I disagree. Getting clever with mutexes indeed looks very wrong 
theoretically, but in practice it'd be a hack that'd be limited to a small 
scope. Assuming it doesn't deadlock (which should be easy to spot) and 
assuming it doesn't have a performance impact, what else can go wrong in 
practice?

-- 
 Luboš Luňák
 l.lunak@collabora.com