[PATCH xserver v3] xwayland: handle EAGAIN on Wayland fd

[Adam Jackson]

On Thu, 2016-09-15 at 12:27 +0300, Pekka Paalanen wrote:

> The blocking X11 calls from the Wayland compositor - are they all of
> the nature that the X server will reply to them immediately when it
> reads them, or could the reply be delayed allowing other X11 clients to
> be serviced in the mean time?

Replies to clients are buffered, and flushes happen whenever the server
thinks it's a good idea [1]. But unlike wayland - or at least, unlike the existing implementation of wayland - when writes to the socket would block, xserver will just keep hold of the output buffer and retry later.

> If all replies are immediate, it sounds like this would be a fairly
> reliable fix after all.
> 

They're not. But it's still an improvement.

If Xwayland can't assume that its wm and wayland server don't block on
each other, then the best it can do is try to limit the amount of
wayland protocol it generates so that it never races too far ahead. I
think to do that you end up wanting a journal of the X client actions
that need to be propagated to the wayland server, doing dead-operation
elimination on it to optimize away things like creating/destroying a
popup window before it's seen (see gtkperf combobox for example), and
syncing that to the wayland server on more or less frame boundaries.
Except, of course, that since the wayland server is also the X window
manager, it can see all those intermediate states...

Really the whole thing would be a lot less fragile if the X server was
just allowed to request window positioning of the wl server and used a
normal window manager "inside" the X session. But noooooo. Can't let
people know where their windows are on the screen, for... some reason.

[1] - Including: when there are damage events pending, when an error is
generated, when the reply being generated would overflow the existing
write buffer, and when we switch which client we're servicing due to
timeslice expiry or client death.

- ajax