plplot-devel

Re: [Plplot-devel] Error report system plus thread safety

[Hazen B. <hba...@ma...>]

>
>> I obviously don't have any idea of the size of ephcom, but Plplot
> must have thousands of internal function calls that would need the
> return value checking.
>
> I believe there are some 300 functions in our public and private API,
> and not all of those will be affected by this (because there are no
> error conditions they generate or they need to propagate). So I would
> estimate "hundreds" of functions rather than "thousands" would be
> touched by this propagation effort.
>
> Also, I think the editing task for propagating return codes would be a
> similar effort to the editing task for replacing the call to plexit by
> the generation of the equivalent message to stderr and an immediate
> return with non-zero return code.  Note, the number of plexit calls is
> 220, from the results of
>
> find . -name "*.c" |xargs grep plexit | wc -l
>
> That number is roughly equivalent to the estimate I made above of the
> number of functions that would be affected by the propagation effort.
> That is the basis of my claim that the two efforts would be
> comparable.

There are also a few functions in the API that already return values 
that would have to be changed. So this would also mean updating all of 
the language bindings and probably some of the examples.

> Anyhow, I am convinced by my above estimate that the propagation part
> of the work will require similar effort to the rest of the project, I
> do like the simplicity of the return code method that has proved to be
> so useful in the ephcom case, and I think the above testing method
> will insure the whole effort will give reliable return code results.
> Also, I think we are talking a few weeks of one-man effort rather than
> months to get this done completely. Therefore, I stand willing (early
> in the next release cycle) to make this happen. Of course, many hands
> make light work so I would welcome some help with this project.

I agree with your time estimate. I also agree that the return codes 
approach is the right way to do it, and even if it does end up taking 
longer than expected it will be more than worth the effort. So I'd be 
happy to help. I guess we'd start with a header file containing a list 
of possible error codes, and then split up the editing of the various 
files in the src/ directory between those who volunteer?

-Hazen

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

On 2016-02-24 06:52-0500 Hazen Babcock wrote:

[Alan]
>> Anyhow, I am convinced by my above estimate that the propagation part
>> of the work will require similar effort to the rest of the project, I
>> do like the simplicity of the return code method that has proved to be
>> so useful in the ephcom case, and I think the above testing method
>> will insure the whole effort will give reliable return code results.
>> Also, I think we are talking a few weeks of one-man effort rather than
>> months to get this done completely. Therefore, I stand willing (early
>> in the next release cycle) to make this happen. Of course, many hands
>> make light work so I would welcome some help with this project.
>
[Hazen]
> I agree with your time estimate. I also agree that the return codes
> approach is the right way to do it, and even if it does end up taking
> longer than expected it will be more than worth the effort. So I'd be
> happy to help. I guess we'd start with a header file containing a list
> of possible error codes, and then split up the editing of the various
> files in the src/ directory between those who volunteer?

Hi Hazen:

I think that would be a good approach, and thanks very much for volunteering
to help with this important project.

Note, I have recently argued for an immediate exit approach for memory
allocation errors which would vastly simplify what we had to do.  But
if you feel strongly that even those errors that only appear for
emergency conditions should be included in the error reporting system,
I would be willing to go along with that.

Also, as noted before I won't have time to work on this project until
the current release is out the door (still something like a month or
so away).  However, if you do have time to work on this now, please
just go ahead on a private topic branch rather than waiting for me.
Right after the current release is out the door you could push your
matured topic branch to master or else if it is not matured by then, I
would be willing and highly motivated to add a lot of energy to the
project at that stage with the goal of getting this topic matured
quickly so we can push it to master not too long after the current
release is done.

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

Hi Hazen:

The propagation issue can be restated as follows: For all functions
where plexit is currently called (except possibly the memory
allocation issues which we might handle differently) you need to
propagate the return code backwards through the "caller graph". The
doxygen application uses the terminology "caller graph" for the call
graph _to_ a given function and simply uses "call graph" for the call
graph _from_ a given function so I adopt that terminology here.  Note,
however, that the wikipedia article
<https://en.wikipedia.org/wiki/Call_graph> on call graphs doesn't
distinguish those two cases.

Anyhow, it turns out that doxygen can generate both call graphs and
caller graphs so I configured (commit b5d5b01) that by setting
HAVE_DOT, CALL_GRAPH and CALLER_GRAPH to YES in doc/Doxyfile.in;
installed the graphviz and doxygen software on my Debian system;
configured cmake with -DBUILD_DOX_DOC=ON; successfully built the
build_doxygen target; and uploaded the html results generated by that
target to our website.  Please check out those doxygen-generated
results by looking at
<http://plplot.sourceforge.net/doxygen/html/plcore_8c.html> which
documents src/plcore.c and associated source files.  The caller graphs
are the ones that are relevant to the present issue of propagating
return codes.

So to take one example, assume in the static void function
plSelectDev that is defined in plcore.c you have just replaced

plexit( "plSelectDev: Too many tries." );

by

return plerror_return(PL_TOO_MANY_TRIES, "plSelectDev: Too many tries.");

where PL_TOO_MANY_TRIES is the return code you have chosen to use to
identify this particular error, plerror_return simply writes the
message to stderr and returns the specified error code, and you have
also modified the type of plSelectDev so it can return a value, and in
particular return a 0 value on success.

Now you want to propagate the case when the return code of plSelectDev
is non-zero. For that purpose, the caller graph for plSelectDev can be found in
<http://plplot.sourceforge.net/doxygen/html/plcore_8c.html>, and that
immediately shows that you have to be concerned about propagation to
just five other functions.  That visual result is much more convenient
than grepping through the source code to find out this information so
I think these type of doxygen results are going to be an enormous help
to us.

One minor caveat is my favorite "konqueror" browser refuses to horizontally
scroll the wide caller graphs so is largely unusable for browsing these
results. Fortunately, I do have access to iceweasel (the Debian brand
for the firefox browser) and that has no trouble with horizontal
scrolling or other rendering issues for these results so you might
want to try firefox there if you are having any rendering trouble
with your favorite browser (if that is different than firefox).

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Chris M. <dev...@gm...>]

On 2/24/2016 15:34, Alan W. Irwin wrote:
> On 2016-02-24 06:52-0500 Hazen Babcock wrote:
>
> [Alan]
>>> Anyhow, I am convinced by my above estimate that the propagation part
>>> of the work will require similar effort to the rest of the project, I
>>> do like the simplicity of the return code method that has proved to be
>>> so useful in the ephcom case, and I think the above testing method
>>> will insure the whole effort will give reliable return code results.
>>> Also, I think we are talking a few weeks of one-man effort rather than
>>> months to get this done completely. Therefore, I stand willing (early
>>> in the next release cycle) to make this happen. Of course, many hands
>>> make light work so I would welcome some help with this project.
> [Hazen]
>> I agree with your time estimate. I also agree that the return codes
>> approach is the right way to do it, and even if it does end up taking
>> longer than expected it will be more than worth the effort. So I'd be
>> happy to help. I guess we'd start with a header file containing a list
>> of possible error codes, and then split up the editing of the various
>> files in the src/ directory between those who volunteer?
> Hi Hazen:
>
> I think that would be a good approach, and thanks very much for volunteering
> to help with this important project.
>
> Note, I have recently argued for an immediate exit approach for memory
> allocation errors which would vastly simplify what we had to do.  But
> if you feel strongly that even those errors that only appear for
> emergency conditions should be included in the error reporting system,
> I would be willing to go along with that.

The problem with immediate exit on memory errors
is that they cannot be caught.  For example, trying to
make a perl binding to plplot would essentially crash
perl if the plplot did an exit.

In FreeGLUT, the fix was to allow an error handler be
called rather than exit.  At that point a python/perl/...
binding could handle the problem.  One example of a
use case is when you are running an interactive session
in the scripting language.  Arguably, running a routine
in the shell shouldn't kill the shell.

--Chris

> Also, as noted before I won't have time to work on this project until
> the current release is out the door (still something like a month or
> so away).  However, if you do have time to work on this now, please
> just go ahead on a private topic branch rather than waiting for me.
> Right after the current release is out the door you could push your
> matured topic branch to master or else if it is not matured by then, I
> would be willing and highly motivated to add a lot of energy to the
> project at that stage with the goal of getting this topic matured
> quickly so we can push it to master not too long after the current
> release is done.
>
> 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
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

Hi Chris:

For a bit of background information for my response to your comment
below note that my counts show that 62 per cent of current plexit
calls are associated with memory allocation errors, but I believe that
fraction will quickly exceed 90 per cent once we become rigourous
about checking for memory allocation issues. So what we do with the
memory allocation errors potentially could matter a lot in terms of
implementation/maintenance costs for our error report system.

On 2016-02-27 10:02-0500 Chris Marshall wrote:

> The problem with immediate exit on memory errors
> is that they cannot be caught.  For example, trying to
> make a perl binding to plplot would essentially crash
> perl if the plplot did an exit.

Understood.

Memory allocation fails only because there are PLplot bugs in
the size of memory requested or because the system is out of memory.

Out of memory is clearly an emergency situation where the operating
system is likely shutting down various programs arbitrarily in any
case to try to claw back some memory.  So under these emergency
conditions an immediate exit from PLplot (and the calling environment
like perl) is not a particularly bad tactic.  And such out-of-memory
emergency conditions are quite rare in any case.

On the other hand, if we do make memory allocation errors part of our
error report system, it does give at least some chance (if the OS does
not kill the perl session first) for the user to save work in an
out-of-memory emergency and if the issue is due to a PLplot size bug,
it gives them (and us) a chance to replicate the issue and debug it
further. So my conclusion is there is a modest benefit to making
memory allocation errors part of the error report system, but that
benefit has to be weighed against the implementation/maintenance
costs.

>From what Phil has said, if we can get the C setjmp/longjmp exception
handling method of error reporting to work then including memory
allocation errors as part of that report system would be fairly
trivial so it would be a no-brainer to do that.  But if we decide to
use the return code method of error reporting the costs of including
memory allocation errors in the system would be significantly higher
(significantly more independent caller paths would have to be dealt
with) so we would have to weigh those costs against the modest (in my
view) benefit discussed above.

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

To Hazen and Phil:

Here is important additional information concerning the return code
method of implementing an error report system that should make that
method very much easier to maintain and test.

Phil originally expressed concern about the amount of developer time
it would take to implement AND maintain propagation of return codes
through all relevant caller paths, and he also proved my proposed
method of testing potentially would not cover all caller paths.  That
combined with the degree of complexity in the caller paths illustrated
by the doxygen results was also making me concerned about PLplot using
the return code method of error reporting.

However, I just discovered a method with gcc that would make the
implementation and maintenance for that method a lot less of a burden.
That method is as follows (see discussion in
<http://stackoverflow.com/questions/2042780/how-to-raise-warning-if-return-value-is-disregarded-gcc-or-static-code-check>
where the focus is on C++, but the method also works for C):

The method uses the 'warn_unused_result' gcc attribute.  A complication is
that we already use the 'visibility( "default" )' attribute for some
gcc cases in include/pldll.h(.in), and combinations of attributes must
be done with a special attribute list syntax.  So the bottom
line is both the 'warn_unused_result' and 'visibility( "default" )'
attributes would have to be combined appropriately in include/pldll.h(.in)
to form the various PLDLLIMPEXP results there.  And that file would
likely also be the best place to implement the
following

#if defined ( __GNUC__ )
#define PL_WARN_UNUSED __attribute__((warn_unused_result))
#else
#define PL_WARN_UNUSED
#endif

(Note that the PL_WARN_UNUSED macro would be needed for all functions
(e.g., static ones) that don't have some form of PLDLLIMPEXP already
deployed in the PLplot headers.)

So, for example, a static function would be declared as

static PLINT PL_WARN_UNUSED pl<function>

Anyhow, assuming all this 'warn_unused_result' attribute
infrastructure had been set up, then gcc should warn whenever an
attempt is made by C/C++ code that calls a PLplot function to ignore
the return code set by that function.  So this gcc
'warn_unused_result' attribute would be an enormous help in finding
and especially testing and maintaining all caller paths that are
relevant to return code propagation.

Anyhow, because of this (very) recent discovery I am once again
confident of going ahead with an implementation of the return code
method of error reporting (including even memory allocation issues
since the cost of those has suddenly gone down) early in the next
release cyle, and it appears Hazen is ready to help with that
implementation as well.

At the same time I have nothing against the alternative setjmp/longjmp
C exception handling error reporting mechanism favored by Phil except
that I don't completely understand it.  But I would be willing to
follow where Phil actively leads on that so let's hear from Phil about
whether his current time constraints allow him to actively lead (i.e.,
doing some active coding and testing rather than making suggestions
from the side) such a development before we make the final decision
about which error reporting mechanism to use.

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Phil R. <p.d...@gm...>]

Hi Alan, Hazen and anyone else interested.

I do agree that memory allocations should not cause exits. I think these cases might be less rare than you think Alan. I work with some very large datasets and have hit memory allocation failures moderately often, although maybe that was more when I was using older versions of visual studio and it built 32 bit executables as standard. A failure of a single very large allocation does not always imply the OS is in crisis.

Yes I'm happy to start putting an exception based error propagation together. Perhaps it would be good for Hazen and Alan to start looking in more detail at implementing the error code propagation? If there are tools to help with that, then maybe it will be easier than I suspect. If someone is implementing both methods then if someone hits a big obstacle then it means we have another option.

I started putting a plmalloc and similar set of functions together today. I'll drop those round for comments asap. Even if we don't go down an exceptions route they should help with generally keeping track of memory and avoiding leaks.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎27/‎02/‎2016 22:47
To: "Hazen Babcock" <hba...@ma...>; "Phil Rosenberg" <p.d...@gm...>; "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] Error report system plus thread safety

To Hazen and Phil:

Here is important additional information concerning the return code
method of implementing an error report system that should make that
method very much easier to maintain and test.

Phil originally expressed concern about the amount of developer time
it would take to implement AND maintain propagation of return codes
through all relevant caller paths, and he also proved my proposed
method of testing potentially would not cover all caller paths.  That
combined with the degree of complexity in the caller paths illustrated
by the doxygen results was also making me concerned about PLplot using
the return code method of error reporting.

However, I just discovered a method with gcc that would make the
implementation and maintenance for that method a lot less of a burden.
That method is as follows (see discussion in
<http://stackoverflow.com/questions/2042780/how-to-raise-warning-if-return-value-is-disregarded-gcc-or-static-code-check>
where the focus is on C++, but the method also works for C):

The method uses the 'warn_unused_result' gcc attribute.  A complication is
that we already use the 'visibility( "default" )' attribute for some
gcc cases in include/pldll.h(.in), and combinations of attributes must
be done with a special attribute list syntax.  So the bottom
line is both the 'warn_unused_result' and 'visibility( "default" )'
attributes would have to be combined appropriately in include/pldll.h(.in)
to form the various PLDLLIMPEXP results there.  And that file would
likely also be the best place to implement the
following

#if defined ( __GNUC__ )
#define PL_WARN_UNUSED __attribute__((warn_unused_result))
#else
#define PL_WARN_UNUSED
#endif

(Note that the PL_WARN_UNUSED macro would be needed for all functions
(e.g., static ones) that don't have some form of PLDLLIMPEXP already
deployed in the PLplot headers.)

So, for example, a static function would be declared as

static PLINT PL_WARN_UNUSED pl<function>

Anyhow, assuming all this 'warn_unused_result' attribute
infrastructure had been set up, then gcc should warn whenever an
attempt is made by C/C++ code that calls a PLplot function to ignore
the return code set by that function.  So this gcc
'warn_unused_result' attribute would be an enormous help in finding
and especially testing and maintaining all caller paths that are
relevant to return code propagation.

Anyhow, because of this (very) recent discovery I am once again
confident of going ahead with an implementation of the return code
method of error reporting (including even memory allocation issues
since the cost of those has suddenly gone down) early in the next
release cyle, and it appears Hazen is ready to help with that
implementation as well.

At the same time I have nothing against the alternative setjmp/longjmp
C exception handling error reporting mechanism favored by Phil except
that I don't completely understand it.  But I would be willing to
follow where Phil actively leads on that so let's hear from Phil about
whether his current time constraints allow him to actively lead (i.e.,
doing some active coding and testing rather than making suggestions
from the side) such a development before we make the final decision
about which error reporting mechanism to use.

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

On 2016-02-27 23:22-0000 Phil Rosenberg wrote:

> I do agree that memory allocations should not cause exits.
[...]
A failure of a single very large allocation does not always imply
the OS is in crisis.

I now agree.

> Yes I'm happy to start putting an exception based error propagation
together.

Thanks very much for being willing to actively lead this effort.

> Perhaps it would be good for Hazen and Alan to start looking
in more detail at implementing the error code propagation? If there
are tools to help with that, then maybe it will be easier than I
suspect.

I am now confident of the return code method because of the
'warn_unused_result' gcc attribute capability, but let's not even
start the substantial work required for this alternative unless it is
made necessary because you run into some showstopper issue with the C
exception-based alternative.

> I started putting a plmalloc and similar set of functions together
today. I'll drop those round for comments asap.

Good idea, and I look forward to seeing what you come up with for the
design of plmalloc and similar.  Also, I would be happy to help
propagate the use of plmalloc and similar throughout our code base
immediately in this release cycle thus effectively getting rid of all
those cases where we have previously been lazy about checking for
memory allocation errors.

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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Hazen B. <hba...@ma...>]

On 02/27/2016 10:10 PM, Alan W. Irwin wrote:
> On 2016-02-27 23:22-0000 Phil Rosenberg wrote:
>
>> Perhaps it would be good for Hazen and Alan to start looking
> in more detail at implementing the error code propagation? If there
> are tools to help with that, then maybe it will be easier than I
> suspect.
>
> I am now confident of the return code method because of the
> 'warn_unused_result' gcc attribute capability, but let's not even
> start the substantial work required for this alternative unless it is
> made necessary because you run into some showstopper issue with the C
> exception-based alternative.

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. To me that 
would be a showstopper issue. However, who does the work decides, so if 
this approach is still your preference then I won't persist in trying to 
dissuade you.

-Hazen

Re: [Plplot-devel] Error report system plus thread safety

[Phil R. <p.d...@gm...>]

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

On 28 February 2016 at 03:47, Hazen Babcock <hba...@ma...> wrote:
>
>
> On 02/27/2016 10:10 PM, Alan W. Irwin wrote:
>>
>> On 2016-02-27 23:22-0000 Phil Rosenberg wrote:
>>
>>> Perhaps it would be good for Hazen and Alan to start looking
>>
>> in more detail at implementing the error code propagation? If there
>> are tools to help with that, then maybe it will be easier than I
>> suspect.
>>
>> I am now confident of the return code method because of the
>> 'warn_unused_result' gcc attribute capability, but let's not even
>> start the substantial work required for this alternative unless it is
>> made necessary because you run into some showstopper issue with the C
>> exception-based alternative.
>
>
> 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. To me that would be
> a showstopper issue. However, who does the work decides, so if this approach
> is still your preference then I won't persist in trying to dissuade you.
>
> -Hazen

Re: [Plplot-devel] Error report system plus thread safety

[Alan W. I. <ir...@be...>]

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 <hba...@ma...> 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
__________________________

Re: [Plplot-devel] Error report system plus thread safety

[Phil R. <p.d...@gm...>]

>
> @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.

actually not that much trouble. We just have plmalloc keep a list of
all memory allocations in a variable in the PLStream and plfree can
remove items from that list. Then we have a free all function which
gets called before the API returns, which frees anything left on the
list. This not only deals with memory leaks after a longjmp, but if we
miss a free anywhere it will also clean up any other memory leaks. I
have already implemented it in the plmalloc/plfree functions I've
written. I'm just adding the calls and I will forward it round.

Phil