> On Mar 24, 2015, at 2:00 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2015-03-24 14:59-0000 Phil Rosenberg wrote: >> >> Probably the biggest issue is the use of plsc. >> >> Consider two threads which both set different streams then call >> another plplot function function. Between the first thread's call to >> set the stream and it's subsequent call to the other function it is >> entirely likely that the second thread will change the current stream. >> The nightmarish issues are obvious. >> This type of one object per calling thread problem seems to be dealt >> with by having some sort of handle which is passed in as the first >> item of each call. Generally this is a void * for opacity. Libcurl >> does this from memory. So we would need something like a >> plstreamcreate function which returns a void* pointer to a plstream >> and is passed in to each subsequent call for that stream, then a >> plstreamfree function would be used to free the memory. > > That large an intrusive API change (and a similar large an intrusive > API change with regard to error returns) sounds like exactly what we > should do for PLplot 6. Thanks to David Howells, my fellow ephcom > developer, we went through a very similar API transition a couple of > years back to finally make ephcom thread safe with a good system > implemented for checking for and returning of error conditions. So I > am already completely convinced we should do something similar for > PLplot 6. > >> At the moment it would probably be possible to make the C++ binding >> thread safe if not thread friendly as we can control exactly when plsc >> is set. This means we could stop the erroneous change of the current >> stream, but we could not have two streams being concurrently run in >> two threads i.e. one would get blocked and we would only be able to >> have one thread within PLplot at any given time. > > I think changing PLplot from a C core library with a C++ interface to > a C++ core library with C interface would be a very large amount of > work compared to relatively simple but intrusive API changes proposed > above. Furthermore, I don't have any C++ expertise at all so the > larger the fraction of PLplot that was C++, the less I could help with it. > So my preference is to keep PLplot a C library but with > straightforward API changes to make it thread safe. > >> I'm not sure we would ever want to use threads internally within >> PLplot. For example to speed up calculations of contours. > > I agree. But thread safety awareness is rising and is already an > important issue for a small but still significant set of developers of > thread-safe software who just need a thread-safe plotting package. So > I think thread safety is one of the more important issues we should > focus on for PLplot 6. And I have similar feelings about the > importance of establishing a system of good error reporting for PLplot > 6. >
One solution to the plsc issue is to use thread local storage. Both gcc and msvc support it. > 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 > __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
