diff options
| author | Hans de Goede <hdegoede@redhat.com> | 2012-03-10 15:22:49 +0100 |
|---|---|---|
| committer | Hans de Goede <hdegoede@redhat.com> | 2012-03-12 12:10:51 +0100 |
| commit | a7841325b22af56355ba353842d3c01b407f26d9 (patch) | |
| tree | b53207a33fd7d4237828c627bc476707c3792951 /python_modules/__init__.py | |
| parent | b023f85ebda1e077d2456ce9e443ea6b3904d58f (diff) | |
| download | spice-a7841325b22af56355ba353842d3c01b407f26d9.tar.gz spice-a7841325b22af56355ba353842d3c01b407f26d9.tar.xz spice-a7841325b22af56355ba353842d3c01b407f26d9.zip | |
red_worker: Rework poll code to use the watch interface
Commit 143a1df24e83e9c1e173c16aeb76d61ffdce9598 changed red_worker_main
from epoll to poll. But epoll has edge triggered semantics (when requested
and we requested them), where as poll is always level triggered. And
red_worker was relying on the edge triggered semantics, as it was always
polling for POLLOUT, which, when edge triggered, would only cause poll
to register an event after we had blocked on a write. But after the
switch to regular poll, with its level triggered semantics, the POLLOUT
condition would almost always be true, causing red_worker_main to not
block on the poll and burn CPU as fast as it can as soon as a client was
connected.
Luckily we already have a mechanism to switch from polling for read only
to polling for read+write and back again in the form of watches. So this
patch changes the red_worker dummy watch implementation into a proper watch
implementation, and drops the entire EventListener concept since that then is
no longer needed.
This fixes spice-server using 400% CPU on my quad core machine as soon as
a client was connected to a multi head vm, and as an added bonus is a nice
cleanup IMHO.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Diffstat (limited to 'python_modules/__init__.py')
0 files changed, 0 insertions, 0 deletions
