On Fri, 1 Feb 2019 at 17:11, Luboš Luňák <l.lunak@xxxxxxxxxxxxx> 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.
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
