> On Feb 22, 2016, at 5:48 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > @Everybody: now on to my C idea for thread safety. > > My idea for implementing that (closely following what was done for the > C ephcom library case where David Howells implemented an ephcom > context to help provide an API that did not depend on static > variables) is to eliminate all static variables by using a > PLplotContext struct that contains all data that is currently stored > as static variables. > > Once that is implemented then the proper non-static way to use PLplot > would be to do something like the following: > > PLplotContext * context; > > context = CreatePLplotContext(); > plparseopts(..., context); > plinit(context); > // other ordinary PLplot calls as usual but with > // context as last argument, e.g., > plline(..., context); > > plend(context); > > where CreatePLplotContext would malloc a PLplotContext, and all the > PLplot API calls would refer to that extra context argument whenever > they needed access to any part of what were previously static variables > (e.g., such as plsc). > > The context-sensitive plend would do everything that plend currently does plus > destroy the context by freeing it. > > So far this follows pretty exactly what David Howells implemented for > ephcom. Does everybody agree this general idea (a comprehensive API > change where a context argument was added to every function call) would > go a long way toward making PLplot thread safe? >
I think that is a good approach. I have done something similar in a mixed C/Fortran environment and it appeared to work, though I did not rigorously test the implementation. The hard part will be chasing down all the static allocations—they abound in the string handling. I had a patch that I put together that removed all the static char arrays used to format information/error messages, but it never made it into the code. I still have the patch and can update and push it to repository now that i can commit. > We found in the ephcom case that both the Python and Fortran bindings > for ephcom could pass the C pointer to a context as arguments. So we > could implement those bindings in a non-static way using the ephcom > equivalent of CreatePLplotContext above. But we retained the static > version of the API just in case some future binding of ephcom was for > a language that could not pass C pointer arguments, and we would also > want to retain the static API for similar reasons in the PLplot case. > > For static versions of plinit, plinit variants (e.g., plstar), and/or > all PLplot routines that can legitimately be called before plinit > would call CreatePLplotContext internally if the static variable > PLplotContextAddress was non-NULL and store that pointer in > PLplotContextAddress which would be referenced by every static PLplot > routine (but PLplotContextAddress would be completely ignored by the > non-static API). > I seem to recall there is a way to get per-thread initialization of variables in C. Is that the direction you want to go or do you want the context address to be shared by all threads? > For backwards compatibility (e.g., to support those who don't care > about thread safety and who do not want to change their code) we would > want to retain the same name for the static API that are used > now. But I would like to use the same names for the non-static cases > as well if that is possible (say by following the approach discussed > at <http://stackoverflow.com/questions/1472138/c-default-arguments>.) > > Further discussion is encouraged and welcome! Also, I am well aware I > have glossed over lots of details here. That is because I frankly > don't completely understand all those details! :-) Nevertheless, > assuming I have expressed the overview correctly of what would be > required, I hope someone will be inspired by that overview to go ahead > and implement the non-static C alternative as a very large step toward > the ability to use our library in a thread-safe way. > > 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 > __________________________ > > ---------- Forwarded message ---------- > Date: Tue, 10 Dec 2002 02:52:43 -0600 (CST) > From: Maurice LeBrun <m...@gazoo.ph.utexas.edu> > To: Alan W. Irwin <ir...@beluga.phys.uvic.ca> > Cc: PLplot development list <Plplot-devel@lists.sourceforge.net> > Subject: Re: [Plplot-devel] plinit, plend, plinit sequence now works, > but I am having second thoughts > > I can't tell you the specific answer to your questions due to how maniacally > busy I am these days (having just joined Lightspeed Semiconductor), but I can > elucidate some of the plplot design ideas that have historically been > un-documented. And, I can give it in an object-oriented context, which > (because it is "canonical") is a lot nicer than the "this is the way it should > work" approach I've used historically. :) > > This also includes proposals for change to how we do it now -- i.e. the > behavior of plinit(). I've always been somewhat bothered by the way stream 0 > vs stream N is handled (this bugged me back in '94 but I wasn't exactly > swimming in free time then either). > > When plplot starts, you have the statically pre-allocated stream, stream 0. > Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper > data-structure/object (in the plframe widget I automatically start from stream > 1). > > So stream 0 is like a class definition and an instance rolled into one. What > I think we need to do is get rid of the "instance" part of this and leave > stream 0 as a "class definition" only. In this case all the command line > arguments and initial pls...() calls (before plinit) serve to override the > default initializion of the class variables, i.e. set stream 0 parameters only > > In other words, stream 0 becomes the template for all plplot streams. You can > use it, but once you've called plinit() you have your own "instance" of the > plplot "object" -- i.e. you have a new stream with all the relevant state info > copied from stream 0. If you change it, it dies when your stream dies with > plend1(). > > If you really want to change stream 0 (i.e. the "plplot object" "class data") > you can always set your stream number to 0 and fire away. > > To summarize: > > plinit() creates a new stream, copied from stream 0 > plend1() deletes that stream > plend() deletes all streams, except of course stream 0 which is "class data" > > Let me know if any of this helps. > > -- > Maurice LeBrun m...@gazoo.ph.utexas.edu > Research Organization for Information Science and Technology of Japan (RIST) > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
