<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Feb 2019 at 17:11, Luboš Luňák <<a href="mailto:l.lunak@collabora.com">l.lunak@collabora.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Calc threading - the Interpret() call may spawn several threads to compute <br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Not ideal in terms of overhead, but less likelyhood of something going wrong in the future.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
- Clipboard handling on Windows - I'm a bit hazy on the technical details, but <br>
if I'm getting it right, OLE requires all clipboard handling to be done by <br>
one thread, which our clipboard code does by creating a dedicated clipboard <br>
thread. Most clipboard operations ask the clipboard thread to do the job and <br>
block waiting for it,</blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> but setting clipboard content is currently <br>
asynchronous, because decoding the set content requires SolarMutex, and again <br>
trying to acquire it from the clipboard thread would deadlock if the main <br>
thread holding it would block waiting for the clipboard thread. But the <br>
current situation with delayed handling can lead to previous clipboard <br>
contents freed too late, causing a crash.</blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">"freed too late" ? sounds like an ownership issue, not a threading issue?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>