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&reg; 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&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to