Hi Alan
Sorry for top posting, I'm replying from my phone.
Just to be clear the strategy I am suggesting is only internal, so that at the
API boundary plplot just returns an error code.
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'm not sure there is any way we can reliably catch them all and the time
investment would be huge.
However, discussions about this shouldn't necessarily impact the api change. We
can still move to a context variable and a error return code and the internals
can be changed as we need.
Phil
-----Original Message-----
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Sent: 23/02/2016 19:00
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
Cc: "Jim Dishaw" <j...@dishaw.org>; "PLplot development list"
<Plplot-devel@lists.sourceforge.net>
Subject: Error report system plus thread safety
Hi Phil:
On 2016-02-23 11:21-0000 Phil Rosenberg wrote:
> Hi Alan and Jim
> I entirely advocate this. This is the same model that libcurl uses
> too. In libcurl the "context" variable is a typecast void* so is
> entirely opaque to the user, but it gets cast to a structure
> internally. I presume the idea would be that the user would use one
> context per thread?
>
[...]
> So in summary:
>
> Pass in a context for helping thread safety - definitely
It appears everyone so far is happy with the context approach.
Furthermore, it appears now with thread-local storage that the address of
the context does not need to be an argument which makes life a lot
simpler for our users.
> Decide how we wish to report an error, could be return val, callback
> or a plgeterr( context ) call.
In the ephcom case, David Howells was kind enough to implement both
thread safety and an error reporting system. The implementation of
the latter uses return values (simply but correctly propagated by each
internal call of an ephcom routine checking for a non-zero error
return and making an immediate return if one of those is detected).
That implementation also uses some C tricks to make it convenient for
a routine encountering an error to print out an error message in
standard form and return with non-zero exit status with one statement.
Furthermore, virtually all PLplot routines right now do not have a
return value which allows us to use return values as part of our error
reporting system. So I lean toward following the ephcom
implementation of an error reporting system based on return values.
Also note that if an application or a library that depends on PLplot
wants to ignore the returned status code for all our C API he can do
so with the above model. So it appears to me that we can implement an
error reporting system and also thread safety without disrupting our
users in any way which is a huge plus in my book.
> If we want to stick with C:
> Create a memory pool for allocating memory and ensuring we avoid memory leaks
> Use longjmp for reporting errors back to the API entry point, but bear
> in mind issues with jumping over C++ code
I prefer the return value approach, see above.
> My personal view is that the error reporting and removing exit calls
> is actually more important than thread safety.
I think we are in basic agreement on this, but I would phrase it
slightly differently; I won't consider PLplot to be a first-class
library until we have both a good error reporting system AND thread
safety implemented. So I am greedy for both. :-)
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
