Temporarily yielding SolarMutex to another thread

[Luboš Luňák <l.lunak@xxxxxxxxxxxxx>]

 Hello,

 does somebody know of a (solution) of a case when it would be useful to make 
another thread temporarily act if it held the SolarMutex? I've recently ran 
into 2 such cases:

- Calc threading - the Interpret() call may spawn several threads to compute 
in parallel a whole formula group. SolarMutex is still held by the main 
thread and the child threads generally try to avoid locking (it's ensured 
beforehand they will operate on distinct data). However, some functionality 
requires SolarMutex and those operations are currently blacklisted for 
threading, since this would deadlock. The main thread cannot release 
SolarMutex just like that in the middle of a computation, another independent 
thread could possibly access a state that's inconsistent at the moment. 
However, the main thread is blocked waiting for its child threads and so 
semantically all those threads "own" the SolarMutex, the child threads are 
there simply to use all CPU cores. I even remember seeing a piece of code 
which simply "silently" (with just a log warning) bails out if it can't 
acquire the SolarMutex.

- Clipboard handling on Windows - I'm a bit hazy on the technical details, but 
if I'm getting it right, OLE requires all clipboard handling to be done by 
one thread, which our clipboard code does by creating a dedicated clipboard 
thread. Most clipboard operations ask the clipboard thread to do the job and 
block waiting for it, but setting clipboard content is currently 
asynchronous, because decoding the set content requires SolarMutex, and again 
trying to acquire it from the clipboard thread would deadlock if the main 
thread holding it would block waiting for the clipboard thread. But the 
current situation with delayed handling can lead to previous clipboard 
contents freed too late, causing a crash. And again, this is really just one 
thread asking another one to do an operation, so again the clipboard thread 
could be semantically considered an owner of SolarMutex during such an 
operation.

 So, has somebody already handled a case like this? And is there a better way 
of handling this than adding some explicit ownership-yield operation to 
SolarMutex? It sounds a bit dirty to do something like that, but I can't 
think of anything better.

-- 
 Luboš Luňák
 l.lunak@xxxxxxxxxxxxx
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice