Hezekiah M. Carty wrote: > On Thu, Sep 24, 2009 at 10:16 AM, Hazen Babcock <hbabc...@mac.com> wrote: >> Hezekiah M. Carty wrote: >>> On Wed, Sep 23, 2009 at 10:41 PM, Hazen Babcock <hbabc...@mac.com> wrote: >>>> Hezekiah M. Carty wrote: >>>> If you are using a language that supports exceptions and callbacks from C >>>> you can override the PLplot's default exit() behavior. >>> I attempted that this evening with OCaml after adding plsabort and >>> plsexit support to the language bindings. Unfortunately, I found that >>> plsexit and plsabort do not override the plabort and plexit behavior. >> Can you write your callbacks so that they never return control to PLplot? > > That is a good point. I just tested this, and at least in the case of > OCaml if the callback raises an exception then control does not return > to PLplot. Do you know if this is safe? I don't want to create > hard-to-debug leaks and corner cases with something like this. A > simple test which raises exceptions on calls to plabort, catches the > exceptions and repeats this process multiple times seems to come out > valgrind-clean on my system, so my initial impression is that this is > safe for at least some of the plabort calls in PLplot. > > plsexit may be less clear as a grep through src/ shows that it is > almost always used for out of memory/failed malloc calls. Different > assumptions may be made when plexit is called, with a greater chance > of memory leaks if the program continues rather than exits. > > This does not address the use of exit() in other areas of PLplot, but > as long as this approach does not create memory leaks it does address > my immediate concern.
I don't really know whether this is actually safe with regards to memory leaks. I'd guess not because I'd imagine that somewhere there is now a stack of commands waiting for a return that is never going to come. Maybe the OS detects this and cleans up this defunct code path? Maybe I have no idea what I am talking about? The test I can think of would be to generate a few thousand exceptions and see if the memory consumption increases and/or you get a stack overflow. -Hazen ------------------------------------------------------------------------------ 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