Replace condition_variable from STL by a monotonic implementation. #1725
Conversation
|
A little update concerning this PR, this bug has been fixed in GCC10 if I'm not wrong. |
|
I assume you are refering to this bug. So that would mean we could scrap the use of our custom condition_variable but keep using It's probably going to be a long time until gcc 10 is installed on most users computers but I'm not sure if maintaining our own version of Also I'm wondering whether or not clang is affected, I would assume not |
Yes it's this bug. It's probably going to be a long time until gcc 10 is installed on most users computers but I'm not sure if maintaining our own version of condition_variable is appropriate, since the issue is easily fixed by restarting polybar in place. Indeed that might be overkill for DST but I remember that someone had a problem with a clock that wasn't working properly but I can't find that issue anymore. |
|
You mean #857? |
This fixes #857 and #1932. Also replaces PR #1725, since we don't need our own implementation of condition_variable anymore since people who update their polybar should have GCC 10 by now. The m_updated_at field of the mpd module was removed instead of having its clock change because it became unused in commit 645a314.
Fixes #857.
Add a re-implementation of
std::condition_variablethat uses the monotonic clock of POSIX.Also replaces the call to
system_clock::now()bysteady_clock::now().EDIT:
Fixes #1932