On 2011-11-03 09:14-0000 Andrew Ross wrote:
> On Wed, Nov 02, 2011 at 05:55:44PM +0000, Steve Schwartz wrote:
>> Hazen,
>>
>> On Tue, 2011-11-01 at 22:28 -0400, Hazen Babcock wrote:
>>> The trick is to write your exit handler so that it does not return
>>> control to PLplot.
>>
>> Indeed, and could be quite tricky depending on the application but is
>> the best plplot could offer. I withdraw the subject line of this thread.
>
> Steve,
>
> This is not at all a stupid question. In fact, it is rather an unfortunate
> historic artefact of plplot. In my opinion, libraries should never call
> exit(). Libraries should return control from a function call as gracefully
> as possible and set an error code. It is up to the application to decide
> what to do from there. For interactive languages then calling exit() is
> exceedingly irritating, just because of a plotting error. This topic has
> come up on the list before, but to fix it requires all plplot functions
> to return error codes. This is a major API change and would also require
> a lot of internal work to ensure errors were handled gracefully. Sadly C
> does not offer a nice way of exception handling unlike some more modern
> languages.
Hi Andrew:
I agree this is an important issue that we need to solve to make
interactive use of PLplot a much nicer experience. However, I
am not sure it needs to be solved with a massive API change.
Here are the current rough plexit statistics:
software@raven> grep plexit drivers/*.c src/*.c |wc -l
228
software@raven> grep plexit drivers/*.c src/*.c |grep -iv mem |wc -l
97
The second command attempts to eliminate the "out of memory" ones from
the result since I assume you do not want to do anything other than
exit for such a major overall system problem.
I am also sure most/all of those ~100 plexit calls in our code have
been done as a "quick fix" when we should have called plwarn instead
and then made some sane assumptions to continue when that is possible
or otherwise do a quick return instead with no plotting action.
Here are my preliminary thoughts on how to deal with this problem:
i. Encourage plexit for truly bad but extremely rare situations. So
every call to malloc or calloc should be checked, and for the
unsuccessful case, call plexit. But I suspect that is the only
case where plexit should be called.
ii. Replace all other calls to plexit with a call to plwarn instead.
There are two cases to consider here.
+ Public API. Replace plexit with plwarn and continue with the
plot when that is possible or do a quick return otherwise. If
our interactive users get a plwarn message when they make a
mistake, and in addition no plot when it is a really bad mistake
that should be sufficient, and I think a return code in addition
would be overkill. The large advantage of this approach is no
API change would be necessary.
+ Private functions. Presumably some of our private functions
that are called by our public API routines currently call plexit
themselves. For this case we should also replace the call to
plexit with plwarn, but we should also return an error code to
our public API routines which should then do a quick return with
no plotting action for non-zero return codes.
My hope is these preliminary thoughts will encourage discussion, and
ultimately a concrete plan that we can all work on together to
eventually produce PLplot libraries that never exit except for the
out-of-memory case.
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
__________________________
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
