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 <[email protected]> wrote:
On Wed, Feb 1, 2017 at 15:02:41 +0100, [email protected] 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.
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
