On 8/9/16 1:59 PM, Nathan Kidd wrote: > On 09/08/16 02:21 PM, DRC wrote: >> The primary reason the destructor exists is to free the shared memory >> segment that VirtualGL uses for its GUI interface. Shared memory >> doesn't get freed automatically. > > If that were the only gotcha, the destructor could handle the shm > segment only, with the GUI activation doing a single "am I dead" check. > It would be nice if every new faker hook/resource access didn't have to > remember about deadYet checks. The whole issue is pretty unintuitive > from a code POV. "I said exit() what do you mean I'm not dead?"
Yeah, but... Once the shared memory segment is destroyed, then we no longer have access to the faker config, and if we no longer have access to the faker config, then it would be very difficult to keep the interposer running with any semblance of normalcy. That's the problem that launched this whole discussion to begin with. The XCB interposer was trying to access fconfig after the singleton had been destroyed. Also, as indicated in the commit message, we really cannot rely on the correct behavior of mutexes when MainWin is shutting down. 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. 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. ------------------------------------------------------------------------------ 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
