xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#691 closed defect (fixed)

win32 shadow server consumes 100% cpu even when inactive

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: critical Milestone: 0.15
Component: server Version: trunk
Keywords: shadow win32 Cc:

Description

shadow servers are inefficient as they use screenscraping, but when the window is not shown, we stop refreshing the pixels - yet on win32, the cpu remains at 100%

Change History (3)

comment:1 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

To make it easier to debug such things, I added r7787 (full stacks for all threads in xpra info), r7785 network debug logging in error path.

And eventually I found that on windows with glib and sockets, we just get lots of spurious EWOULDBLOCK, see
Watching sockets with Glib on Windows puts them in non-blocking mode, because glib puts the socket in non-blocking mode.. and we just can't force it into blocking mode (I've tried).

So, r7790 does an ugly fix and introduces an up to 5ms sleep in the socket loop for win32 sockets (it starts at 0ms and goes up to 5ms) which isn't as good as blocking sockets or a working non-blocking polling implementation... but keeps the changes minimal. The win32 will wakeup up to 200 times per second on those sockets, but this barely registers in terms of CPU usage now.

I have also tested the win32 client to make ensure that this does not make any difference there.
The win32 shadow server is quite broken in 0.14.x already, not sure this is worth backporting, closing.

comment:2 Changed 5 years ago by Antoine Martin

Backport in r7811.

comment:3 Changed 3 years ago by Antoine Martin

r13270 moves the win32 socket workaround code to win32 servers only. (no need to penalise win32 clients)

Note: See TracTickets for help on using tickets.