From: Phil R. <p.d...@gm...> - 2016-02-23 23:36:51
|
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...@be...> Sent: 23/02/2016 19:00 To: "Phil Rosenberg" <p.d...@gm...> Cc: "Jim Dishaw" <ji...@di...>; "PLplot development list" <Plp...@li...> 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 __________________________ |