On 2016-02-23 00:50-0500 Jim Dishaw wrote: > >> 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? Thanks for that idea which I frankly had never heard of before, but now you have drawn my attention to that possibility (e.g., <https://en.wikipedia.org/wiki/Thread-local_storage>) it would be a vast simplification since we would no longer need to carry the context argument to each routine because instead you could store context as a static thread-local variable. In other words, if I am interpreting what that article said properly, what I have described as the static case could be made thread safe by simply changing the static variable PLplotContextAddress to a static thread-local variable. One complication for this exciting prospect for PLplot thread safety is according to the article above this C capability was only introduced in C11. So it is apparently going to take a while for C compilers to support thread-local capability in a standard way. For example, according to <https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html> gcc does support thread local storage but currently in a non-standard way using the "__thread" attribute. On my system the following compiles without issues for gcc-4.9.2: irwin@raven> cat test_thread_local.c static __thread int foo = 0; irwin@raven> gcc -c test_thread_local.c -o test.o So that support for the __thread attribute looks promising. Anyhow, I think the next step forward is to follow up with the "static" implementation I described above with PLplotContextAddress initially declared for testing purposes as static __thread PLplotContext * PLplotContextAddress; for gcc (4.9.2 and above) and static PLplotContext * PLplotContextAddress; otherwise. I hope someone here is keen to give this idea a try. 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
