On 2016-02-28 16:42-0000 Phil Rosenberg wrote: > Do we do any other resource allocation other than memory? I guess we > deal with files too, so that answer makes a good point that they need > considering too. > It's not quite just a goto. The registers are all reset too, so the > stack pointer function pointer etc are all put back, but you are > correct that the stack is left as it was so any allocated resources > get left. They therefore need managing in a way that they can be freed > when the plplot returns. > > What I really don't want to do here is obfuscate the code to the point > where others are not happy to tinker with things. I'm starting to feel > that there is a real risk of that. What I will do is set up a single > API function to use setjmp and longjmp and I will send that around as > a patch. If and only if there is consensus that people are happy with > how this works then I will continue.
@Phil: I think this cautious approach is a good initial plan but also note my further comments below about the advantages below of simply ignoring resource leaks. > On 28 February 2016 at 03:47, Hazen Babcock <hbabc...@mac.com> wrote: >> Before you begin I would encourage you to read this: >> >> http://stackoverflow.com/questions/14685406/practical-usage-of-setjmp-and-longjmp-in-c >> >> Particularly the 2nd and 3rd answers. As they point out, this is *not* C++ >> exception handling in C, this is just a goto statement. @Hazen: The following quote from your reference "So allocations, locks, half-initialized data structures, etc, are still allocated, locked and half-initialized when you get back to where setjmp was called." is definitely a good point to remember. However, we are dealing in each case (where plexit is currently called) with a showstopper PLplot error where we want to call plend (as plexit currently does) to kill the PLplot library, and then return control to the user's environment rather than doing a raw exit. Under these circumstances I think it is OK to be sloppy with regard to left over memory allocations that are not already killed off by plend. I suppose such memory and other resource leaks could be a problem if the PLplot library was being initialized zillions of times by a user with all error conditions ignored, but otherwise I don't think such resource leaks from PLplot showstopper errors are that important an issue. For this reason I had no plans whatsoever to be careful to free memory in routines that were propagating an error condition down the caller map because that would make an already difficult editing task substantially more difficult for not much (in my view) benefit. So my return code implementation would have been functionally equivalent to longjmp. @Phil: I assume with a lot of trouble (such as implementing more centralized control of our memory allocations) you could deal with resource leaks using the setjmp/longjmp approach, but for the above reason I don't think you should bother. @Phil and Hazen: In sum, I think this is one of those cases where a search for perfection is a substantial hindrance to progress. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
