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.
On 8/9/16 1:09 PM, Nathan Kidd wrote: > On 09/08/16 12:13 AM, DRC wrote: >> A proper fix for this, resulting from today's remote debugging session, >> has been pushed to master. Please see >> >> https://github.com/VirtualGL/virtualgl/commit/a143bf303940b46bf8b9a993907ac352709871b8 >> >> for my analysis and a roll-up of past MainWin and/or ANSYS issues that >> are directly related to this or have similar causality. Let me know if >> there are further problems. > > Thanks. > > Re: "This issue may have also affected other > +applications that use MainWin." > > I know for a fact ANSYS Maxwell was also affected, and expect others. > I'll ask QA when they test this instead of the patches I've been carrying. > > I've been pondering what benefit we actually get from the VGL > destructors. Once the process exits all memory will be freed. Once any > X sockets disconnect the X server will free any associated resources. > We wouldn't need any isDead resource guards if we didn't kill anything > and let the OS/X server handle it. Can you think of a down side? > > -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
