[PR #656] [MERGED] Fixes high cpu usage spikes on win10 #1671

Closed
opened 2026-05-05 07:59:08 -06:00 by gitea-mirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/debauchee/barrier/pull/656
Author: @galkinvv
Created: 5/6/2020
Status: Merged
Merged: 6/4/2020
Merged by: @p12tic

Base: masterHead: fix-win10-cpu-usage-spikes


📝 Commits (2)

  • 8ab6ad6 Remove unused IEventQueue::isEmpty() method to simplify code understanding
  • 95f2a84 Windows 8+: make waiting for messages correspond to emptiness check

📊 Changes

5 files changed (+13 additions, -18 deletions)

View changed files

📝 src/lib/base/EventQueue.cpp (+0 -6)
📝 src/lib/base/EventQueue.h (+0 -1)
📝 src/lib/base/IEventQueue.h (+0 -7)
📝 src/lib/platform/MSWindowsEventQueueBuffer.cpp (+12 -4)
📝 src/lib/platform/MSWindowsEventQueueBuffer.h (+1 -0)

📄 Description

Using barrierc on windows10 I noticed that sometimes but quite often, say 1 times of 5 opens of a task manager (even when server is offline) it begins utilizing 100% of a cpu core.

Fixes high cpu usage spikes on win10.
When queue was containing messages of only non-QS_POSTMESSAGE type the
"while (m_buffer->isEmpty())" busy-looped in EventQueue::getEvent
since isEmpty was true (checked only QS_POSTMESSAGE message type),
but waitForEvent returned immediately (checked more message types).

Investigation shows that the difference was introduced in
dbfb04a6e
to fix a problem with bad behaviour of GetQueueStatus
Researching showed that a similar problem was fixed in Qt,
and the solution was
"pass different flags to GetQueueStatus depending on version of windows"
https://bugreports.qt.io/browse/QTBUG-29097

So this patch makes changes to a barrier non-GUI core similar to Qt fix.

Unfortunately I'm not using barrier often now, so only basic tests were performed and only windows as a client, not as a server.

However, this PR is created since the problem may be common, so more testers may appear)


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/debauchee/barrier/pull/656 **Author:** [@galkinvv](https://github.com/galkinvv) **Created:** 5/6/2020 **Status:** ✅ Merged **Merged:** 6/4/2020 **Merged by:** [@p12tic](https://github.com/p12tic) **Base:** `master` ← **Head:** `fix-win10-cpu-usage-spikes` --- ### 📝 Commits (2) - [`8ab6ad6`](https://github.com/debauchee/barrier/commit/8ab6ad64f9a570a5529f77dd2e99175bf46995d0) Remove unused IEventQueue::isEmpty() method to simplify code understanding - [`95f2a84`](https://github.com/debauchee/barrier/commit/95f2a840be42b7fb92317a14d04f4dd047405660) Windows 8+: make waiting for messages correspond to emptiness check ### 📊 Changes **5 files changed** (+13 additions, -18 deletions) <details> <summary>View changed files</summary> 📝 `src/lib/base/EventQueue.cpp` (+0 -6) 📝 `src/lib/base/EventQueue.h` (+0 -1) 📝 `src/lib/base/IEventQueue.h` (+0 -7) 📝 `src/lib/platform/MSWindowsEventQueueBuffer.cpp` (+12 -4) 📝 `src/lib/platform/MSWindowsEventQueueBuffer.h` (+1 -0) </details> ### 📄 Description Using barrierc on windows10 I noticed that sometimes but quite often, say 1 times of 5 opens of a task manager (even when server is offline) it begins utilizing 100% of a cpu core. Fixes high cpu usage spikes on win10. When queue was containing messages of only non-QS_POSTMESSAGE type the "while (m_buffer->isEmpty())" busy-looped in EventQueue::getEvent since isEmpty was true (checked only QS_POSTMESSAGE message type), but waitForEvent returned immediately (checked more message types). Investigation shows that the difference was introduced in https://github.com/debauchee/barrier/commit/dbfb04a6e to fix a problem with bad behaviour of GetQueueStatus Researching showed that a similar problem was fixed in Qt, and the solution was "pass different flags to GetQueueStatus depending on version of windows" https://bugreports.qt.io/browse/QTBUG-29097 So this patch makes changes to a barrier non-GUI core similar to Qt fix. Unfortunately I'm not using barrier often now, so only basic tests were performed and only windows as a client, not as a server. However, this PR is created since the problem may be common, so more testers may appear) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
gitea-mirror 2026-05-05 07:59:08 -06:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#1671
No description provided.