Hi Alan et al Please find attached some patches that show some bare bones start to using setjmp and longjmp exception style error handling in plplot. Please have a look at the log for a detailed description of what is going on and how it works.
What this is: A first start with enough code to show the basic principles of how this could work. What this isn't: A fully working version that should go anywhere near the actual repo. I have only tested to see if it compiles, builds and that x00c runs. In fact I get some tcl related exception on exit, which I'm not sure if I just caused or if it was there before. I am sending out this super early untested code that may still have major bugs and is based on whatever (quite old) plplot source I happened to have on my machine so that you can see the PRINCIPLES of how it works. And because I have other stuff on today so I might not get chance to look at this for a while and I know Alan was keen to see something asap. So feel free to be critical, but please not too critical :-) Alan, have a look, have a play. Thoughts welcome. Phil On 16 July 2017 at 00:24, <p.d.rosenb...@gmail.com> wrote: > Hi Alan > > Proof of concept was a little more than 20 or so lines 😉 > > > > I'll pull out the code I started and check where is stands. > > > > Phil > > > > Sent from my Windows 10 phone > > > > *From: *Alan W. Irwin <ir...@beluga.phys.uvic.ca> > *Sent: *15 July 2017 21:50 > *To: *Phil Rosenberg <p.d.rosenb...@gmail.com>; Ole Streicher > <debian-de...@liska.ath.cx> > *Cc: *Hazen Babcock <hbabc...@mac.com>; andrewr...@users.sourceforge.net; > PLplot > development list <plplot-devel@lists.sourceforge.net> > *Subject: *First proof-of-concept step requested to implement PLplot > errorhandling > > > > On 2017-07-15 11:49+0200 Ole Streicher wrote: > > > > > Another (probable longer-standing) topic would be the use of exit() in > > > several libraries in case of error. That usually has the disadvantage > > > that it makes debugging more complicated, since you don't get a > > > stacktrace; abort() may be the better solution here. Any thoughts about > > > that? > > > > To Phil and Ole (with CC to Hazen and Andrew): > > > > @Phil: > > There is a key question for you at the end. > > > > @Ole: > > > > Here is some background on the issue you brought up above. > > > > An even more important issue with exit that concerns PLplot developers > > is, for example, some poor guy has been working on some interactive > > session for 4 hours, (e.g., octave) and then attempts to finish up by > > plotting his results, but he makes a wrong PLplot call ==> exit, loses > > all those 4 hours of work! Not pretty! > > > > The obvious solution is to implement a proper error handling system > > for the PLplot libraries, bindings libraries, and device drivers that > > avoids the use of exit and simply propagates an error condition to > > whatever library or user routine calls PLplot routines if something > > goes wrong anywhere in any of the PLplot-related source code. > > > > We have discussed here fairly recently the best way to implement such > > an error handling system. There have been two schools of thought about > > how we implement that which I will attempt to summarize here. > > > > 1. Implement our error handling using normal C methods. That is, > > change our API to return an error code for each PLplot routine that > > can possibly have an error condition or which calls a PLplot routine > > that itself could have an error condition. (This turns out to be most > > PLplot-related routines). Then those error conditions codes must be > > checked and propagated further if necessary after virtually all > > returns from PLplot routines that occur within the PLplot libraries, > > bindings libraries, and device drivers. > > > > 2. Implement our error handling system using longjmp and setjmp > > > > See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html> > > for an example of how to use those two C library routines (both > > available since c89 and also supported by Windows) to implement > > exception handling in C that is quite similar to exception handling in > > C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based > > error handling system he was unaware of this example so his proposal > > likely varied in many details from this example. But the overall > > principle was the same which is you can use these two functions to > > avoid the laborious process of having to propagate error codes via > > function return values. > > > > Andrew Ross and Hazen Babcock liked the first idea because it is the > > standard C way to implement error handling. Phil and I liked the > > second idea because it is a lot less work (the PLplot call graphs are > > extraordinarily complex so there are potentially huge numbers of > > Plplot routine return values to check within the PLplot libraries, > > bindings libraries, and device drivers). > > > > The above reference on C exception handling mentioned an issue many C > > programmers have with longjmp/setjmp which is they are completely > > unfamiliar with their use. And I think PLplot developers (including > > me) do indeed have such unfamiliarity concerns. So to help us get > > more familiar with their use, I asked Phil the last time we discussed > > this to implement a simple proof of concept of his idea (e.g., a > > modification of plexit that unwinds the stack and delivers an error > > message to a single convenient place in our PLplot core library > > (likely our library initialization) where setjmp is called to set > > everything up.) I suspect Phil just plain forgot about that request > > due to other time pressures on him so I am taking this opportunity to > > make that request again. :-) > > > > @Phil: > > > > I am still just as unfamiliar (except for what I read in man pages) as > > the rest of our developers with longjmp/setjmp. So are you game to > > implement such a simple proof-of-concept to help us become more > > familiar with those two routines? > > > > If so, how about dealing with it right away (after all, I think we are > > only dealing with something like ~20 lines of code) to avoid losing it > > again in your stack of PLplot e-mail? This variant of plexit should > > only be compiled if the user specifies the -DHAVE_ERROR_HANDLING=ON > > experimental CMake option which should default to NO to provide > > sufficient safety that if you act fast you can safely merge this with > > the master branch in time for the 5.13.0 release. > > > > The goal of such a simple proof of concept would merely be to confirm > > the stack was properly unwound by longjmp with a message right after > > the single place in the PLplot library that you call setjmp during > > library initialization. If that call returns 0 (i.e., it is the > > initial call made during library initialization) then no message would > > be generated, but it it returns non-zero (i.e, the result of longjmp) > > then generate a "this proof-of-concept is working" message before (for > > now) exiting just like ordinary plexit does. So this simple proof of > > concept would be restricted to inside the PLplot core library, and the > > gory details of how to propagate error reporting across the boundaries > > of our PLplot libraries, bindings library, and device drivers would be > > ignored for now. Of course, this proof of concept would be far from a > > full solution for our much needed error handling system, but it could > > be a very important first step in achieving that important PLplot > > goal. So how about taking that first step now? > > > > 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 > > __________________________ > > >
0001-Added-functions-that-will-record-memory-allocations-.patch
Description: Binary data
0002-Added-Memory-allocation-function-declarations-to-plp.patch
Description: Binary data
0003-Added-Exception-handling-macros-functions-variables.patch
Description: Binary data
0004-Add-some-test-code-for-exception-handling.patch
Description: Binary data
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
