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. Thanks, -- A. Huillet _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
