On 09/08/16 04:31 PM, DRC wrote: > One thing I haven't investigated is whether creating our own equivalent > of _fini() would change the destruction order. At one time, I couldn't > set up a global destructor function because the versions of Solaris and > Sun Studio we were supporting didn't allow for that, but that is no > longer the case. However, unless it would change the destruction order, > thus guaranteeing that the faker is destroyed last, then it wouldn't > allow us to simplify anything.
In my experience the _init()/_fini() calling sequence is at least system dependent (I could reproduce things on one Linux distro, not another), and I don't suppose Linux is that different from Solaris when it comes to the insanity described here: https://blogs.oracle.com/rie/entry/init_and_fini_processing_who > And yes, I get how deadYet checks create a developer-proofness problem, > but realistically, how often do new X11 functions get introduced into > the VirtualGL code? No point beating our heads against the wall to make > a very rare case slightly easier. It takes exactly two seconds to > copy/paste the deadYet check from another function. The deadYet check > is just one of several checks that we have to perform on a > function-by-function basis, such as making sure that the XCB functions > aren't interposed if they are called within the body of an > already-interposed X11 function, and in some cases making sure that the > X11 functions aren't interposed if they are called within the body of an > already-interposed GLX function. Given that I do most of the > development on VirtualGL, I certainly want to make it as straightforward > as possible to develop, but there's only so much that can be done in > this case. Fair enough. -Nathan ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
