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
