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
__________________________