On 2017-07-23 06:00-0700 Alan W. Irwin wrote: P.P.S. As I am just discovering, one of the huge problems in this field is terminology. For example, the wikipedia article <https://en.wikipedia.org/wiki/Call_stack> refers immediately to 6 synomyms (ouch!) for call stack with one of those being just plain "stack" which is the terminology used by the Linux man pages for setjmp and longjmp.
"Call chain" is not one of those wikipedia-approved synonyms, but I believe I must have picked up that terminology from another article I read (where it meant the same thing). Therefore, since the principal terminology in wikipedia is "call stack", that is much preferable to the "call chain" terminology I used below. But nevertheless, I thought I did pretty well below considering I wrote that at 6 o'clock in the morning after a long night of analysis without sleep. :-) Alan
P.S. I just reviewed the wikipedia article on call graphs, and it appears I was misusing that term and should have used call chain instead where a call graph for a given library consists of all the potential call chains in the library with each one starting at one of the public API's. So my understanding now is the PLTHROW macro in plexit unwinds the particular call chain that called plexit until it reaches the first routine higher in that call chain where the the call was made in a PLTRY block and transfer control to the code in the corresponding PLCATCH block. @Phil: Do you agree with this explanation of PLTHROW, PLTRY, and PLCATCH or does it need further correction? If that explanation is substantially correct, that one scenario I was discussing could be described as two possible call chains in the call graph with one starting at the first public API traversing through the second public API and eventually traversing to plexit, and the second starting at the second public API and eventually traversing to plexit as well. So the question was does the code need enhancement to deal with those two different possible call chains where in one case the PLCATCH block of the second API needs to PLTHROW to unwind the call chain to the first API PLTRY and transfer control to the corresponding PLCATCH block, and in the other case the second API catch block needs simply to return to the calling routine in the external application. And similarly this change in terminology needs to be applied to my just-previous discussion of other topics related to PLTHROW, PLTRY, and PLCATCH. 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 __________________________ ------------------------------------------------------------------------------ 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
__________________________ 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 __________________________ ------------------------------------------------------------------------------ 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
