diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2020-06-19 14:52:34 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2020-06-23 18:04:38 -0700 |
commit | 001c13da0690b9eb6d7d5642099479e63041fbec (patch) | |
tree | 6e6787dbbd62d8e965ab1638d1ffee3087e773d5 /gtk-recordmydesktop/INSTALL | |
parent | 1c4174855664744595541347afecfea1fb919b52 (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/INSTALL')
0 files changed, 0 insertions, 0 deletions