Re: Temporarily yielding SolarMutex to another thread

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.

Not ideal in terms of overhead, but less likelyhood of something going
wrong in the future.



> - 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,


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.

> 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.


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

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.

>