[Xcb] [Bug 92652] _XReadEvents is treating EAGAIN as a fatal error instead of just trying again

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

--- Comment #7 from Jeremy Huddleston Sequoia <***@freedesktop.org> ---
_xcb_conn_wait is returning false in here:

while(!(ret = get_event(c)))
if(!_xcb_conn_wait(c, &c->in.event_cond, 0, 0))
break;

FWIW, this is true for both the poll and select codepaths.

Need to dig into this more later.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

Jeremy Huddleston Sequoia <***@freedesktop.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Product|xorg |XCB
Component|Lib/Xlib |Library
QA Contact|xorg-***@lists.x.org |***@lists.freedesktop.org

--- Comment #5 from Jeremy Huddleston Sequoia <***@freedesktop.org> ---
xcb_generic_event_t *event;
dpy->xcb->event_waiter = 1;
UnlockDisplay(dpy);
event = xcb_wait_for_event(dpy->xcb->connection);
/* It appears that classic Xlib respected user
* locks when waking up after waiting for
* events. However, if this thread did not have
* any user locks, and another thread takes a
* user lock and tries to read events, then we'd
* deadlock. So we'll choose to let the thread
* that got in first consume events, despite the
* later thread's user locks. */
InternalLockDisplay(dpy, /* ignore user locks */ 1);
dpy->xcb->event_waiter = 0;
ConditionBroadcast(dpy, dpy->xcb->event_notify);
if(!event)
_XIOError(dpy); // Here's where we're bailing.

So xcb_wait_for_event() is returning NULL.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

--- Comment #9 from Jeremy Huddleston Sequoia <***@freedesktop.org> ---
Looks like the WM is calling XKillClient():

(lldb) bt
* thread #3: tid = 0x20aab8, function: CloseDownConnection , stop reason =
breakpoint 5.1
* frame #0: 0x0000000101f44780 X11.bin`CloseDownConnection
frame #1: 0x0000000101e1f804 X11.bin`CloseDownClient + 484
frame #2: 0x0000000101e3a84a X11.bin`ProcKillClient + 314
frame #3: 0x0000000101e1ebf4 X11.bin`Dispatch + 1172

And digging into quartz-wm's code, we see:

- (void) do_close:(Time)timestamp
{
TRACE ();

if (_does_wm_delete_window)
{
XEvent e;

e.xclient.type = ClientMessage;
e.xclient.window = _id;
e.xclient.message_type = atoms.wm_protocols;
e.xclient.format = 32;
e.xclient.data.l[0] = atoms.wm_delete_window;
e.xclient.data.l[1] = timestamp;

XSendEvent (x_dpy, _id, False, 0, &e);
}
else
{
XKillClient (x_dpy, _id);
}
}

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

--- Comment #10 from Jeremy Huddleston Sequoia <***@freedesktop.org> ---
Uli, yep, moving the XSetWMProtocols() ahead of the XMapWindow() causes this to
behave as expected. So now I just need to figure out what the correct behavior
is here. My ICCCM is a bit rusty, but this is wither a bug in the WM or in the
test app.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

--- Comment #6 from Jeremy Huddleston Sequoia <***@freedesktop.org> ---
If I keep retrying, xcb_wait_for_event eventually errs with ETIMEDOUT
instead... hmm...

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

--- Comment #8 from Uli Schlachter <***@znc.in> ---
Could you try moving the code that sets up WM_PROTOCOLS / WM_DELETE_WINDOW from
event_loop() into create_window() (*before* the call to XMapWindow())? (No, I
do not have a Mac where I could test this myself)

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92652

Jeremy Huddleston Sequoia <***@freedesktop.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Product|XCB |XQuartz
Version|unspecified |2.7.8 (xserver-1.16.4)
QA Contact|***@lists.freedesktop.org |***@freedesktop.org
Component|Library |quartz-wm