[PATCH libX11] _XDefaultError: set XlibDisplayIOError flag before calling exit

[Arthur Huillet]

With Jamey's review and Julien's questions answered, would someone 
please push that change to libX11, unless there are objections to the 
patch?

Thank you
-- 
A. Huillet

On 2017-02-02 9:45, Arthur Huillet wrote:
> On Thu, 2 Feb 2017 09:05:03 +0100
> Julien Cristau <jcristau at debian.org> wrote:
> 
>> On Wed, Feb  1, 2017 at 15:02:41 +0100, arthur.huillet at free.fr wrote:
>> 
>> > It is legal for an application to make Xlib calls during _fini, and that is useful for an OpenGL driver to avoid resource leaks on the X server side, for example in the dlopen/dlclose case. However, the driver can not readily tell whether its _fini is being called because Xlib called exit, or for another reason (dlclose), so it is hard to cleanly work around this issue in the driver.
>> >
>> I don't get the resource leaks justification.  Can't the X server 
>> clean
>> up when the client goes away?
> 
> My change is safe precisely because of that: when the client goes
> away, that is, when the display connection dies, the X server will
> clean up correctly. Therefore it doesn't matter if Xlib went into
> "no-op" mode when it called exit.
> However, _fini is also called for the hairy case of dlclose(). If an
> application loads the OpenGL driver with dlopen(), and closes it with
> dlclose(), then its display connection is likely still alive and not
> dying, in which case the X server will not clean up correctly.
> Quake3 used to be known as one of the applications that did that. It
> would dlclose then dlopen again the driver whenever some video
> parameters were changed in the menu.
> 
> This is a strange use case, but it's legal, and isn't becoming less
> relevant with glvnd (thanks to which the driver is now *always* loaded
> via dlopen). glvnd would theoretically be free to call dlclose if it
> fancies that, although I'm not aware that it does it at this point. I
> also seem to remember seeing dlclose called by the Vulkan loader.
> 
> Generally speaking it's difficult for a driver to handle resource
> cleanups with threads, forks, and dlclose. Unfortunately all these
> happen in the wild, usually together (at least in our internal stress
> tests), so we have to "support" them.