On 20 Jun 2005 Carl Worth wrote to the mailing list about XCBConnect failing occasionally. IIRC, Keithp said that this is due to the X server being coded for old OS limitations, and Xlib just auto-retries in this case.
XCB needs to handle connection errors better; see libxtrans/Xtranssock.c for how it's been handled in Xlib. Patches welcome. :-) For TCP sockets there's this comment, with a similar but different set of issues for Unix sockets: If the error was ECONNREFUSED, the server may be overloaded and we should try again. If the error was EWOULDBLOCK or EINPROGRESS then the socket was non-blocking and we should poll using select If the error was EINTR, the connect was interrupted and we should try again.
I don't recall exactly what Keithp thought was happening. That said, I'm really uncomfortable with putting this kind of policy in core XCB, which is supposed to be all about mechanism. I guess what I'd recommend is putting a routine in aux which is a persistent-attempt-to-open built on top of XCB core. Maybe. Among other things, I think the security implications of auto-retry are a bit interesting. I can't offhand see where this breaks security in obvious ways, but I can imagine attempts to spoof an X server being aided and abetted...
From a quick look, I can't see where (current, xcb-ified) Xlib would do retry. XOpenDisplay() calls _XConnectXCB() which just calls into xcb_connect() once. If that fails, Xlib retries with other protocols. No looping involved...? Did Xlib do better pre-xcb?
> That said, I'm really uncomfortable with putting this kind of policy in core XCB, which is supposed to be all about mechanism. I guess what I'd recommend is putting a routine in aux which is a persistent-attempt-to-open built on top of XCB core. Maybe. Yeah, I agree.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.