summaryrefslogtreecommitdiff
path: root/gtk-recordmydesktop/ChangeLog
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2020-06-19 14:52:34 -0700
committerVito Caputo <vcaputo@pengaru.com>2020-06-23 18:04:38 -0700
commit001c13da0690b9eb6d7d5642099479e63041fbec (patch)
tree6e6787dbbd62d8e965ab1638d1ffee3087e773d5 /gtk-recordmydesktop/ChangeLog
parent1c4174855664744595541347afecfea1fb919b52 (diff)
*: first attempt to unfuck thread synchronization
I'm already regretting this... I don't think the author understood how condition variables work, that signal/broadcast is purely synchronous with blocked waiters - they don't queue a "signaled" state. So all these cond_waits littered everywhere without any explicit stateful condition being watched, if they didn't happen to be sitting in the wait when the signal occurred, that signal event was lost, and blocking would persist until the next one. Even if the wait only *just* missed the arrival due to scheduling, it was a very racy and broken use of condition variables. Not to mention the possibility of spurious wakeups... You *always* need some shared state to use condition variables properly, it's why they include a mutex; to protect the shared state. If you're not writing a while() loop to wait on a condition variable, you're almost certainly doing it wrong. This stuff will continue to evolve as I get around to it.
Diffstat (limited to 'gtk-recordmydesktop/ChangeLog')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved