On Thu, Sep 24, 2009 at 4:27 PM, Andrew Ross <andrewr...@users.sourceforge.net> wrote: > On Thu, Sep 24, 2009 at 02:15:27PM -0700, Alan Irwin wrote: >> On 2009-09-24 21:34+0100 Andrew Ross wrote: >> >>> plexit calls plend _after_ the exit handler is called, and so if the exit >>> handler >>> throws an exception plplot will not call plend to tidy up and free memory. >>> Provided >>> that you do this yourself in your handler then you _should_ be ok. >>> >>> Of course, we would need to check all code paths with plexit in to make >>> sure they >>> don't leave any locally allocated memory unfreed. I don't know whether this >>> is the >>> case. It has probably never been thoroughly tested since we only tend to run >>> valgrind on the examples which are set up not to generate any errors.
I think that this would be a valuable change in PLplot for interactive use - at least Octave and OCaml offer this and I would guess that Python, Perl/PDL and others may as well. As others mention in this thread, the application may not e left in the safest state (out of or almost out of memory for example), but that is often better that forcing an exit. >> Sorry for entering late to this conversation. I may have missed some key >> piece of information earlier in the thread, but let me ask a "dumb" >> question, anyway. plexit ultimately calls exit, which AFAIK immediately >> exits without returning control to the routine that called the plplot >> library in the first place. So plexit should be reserved (and I think it >> normally is) for truly catastrophic errors where no means exist to recover. >> For that case where a castrophe is occurring anyway, why are we concerned >> about memory management issues? Why does plexit even bother to call plend? >> Shouldn't it just send a message about the castrophic error and exit? > > Well only in the sense that it is good programming practice and will also > do things like close file handles etc. I suppose you might manage to > rescue part of a multipage plot if it had been properly closed... > > The question becomes much more important if you are going to do something > in your exit handler, i.e. throw an exception, which means exit is _not_ > called. > > An example of why you might want to do this is the octave bindings. Doing > something stupid which results in a call to plexit then kills the whole > of octave. Bitter experience teaches me that this is almost always not > what you want to happen in this interactive setting. The plsexit documentation could warn that exception-raising callbacks should call plend if they want to attempt to rescue whatever plots are currently in progress. These exceptions can also help track down where the error occurs in the code if they include a backtrace. This can save a lot of time when tracking down an error of this sort, even in compiled/non-interactive code. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
