On 2014-10-08 11:21+0100 Phil Rosenberg wrote:
> Hi Arjen
> I did try to do that. However, we of course have the main thread calling
> Plplot routines, which means the thread running wxWidgets cannot. This means
> the wxWidgets driver cannot access the plstream pointers at all. In
> particular the current stream pointer - as this may change mid render.
> Because many plplot internal and external functions access the streams and
> other globals they are not thread safe either so cannot be called from the
> driver. Even things like the buffer for rerendering become out of bounds I
> think.
>
> I got quite far with this, but the final nail was trying to deal with
> plfreetype. We have since agreed to remove freetype dependence from wxWidgets
> which is on my to do list. Then I will reassess how possible this is. It
> might mean a stripping of some functionality from the wxPlplotWindow and/or
> wxPlplotFrame where calls back to plplot are required and it will pretty much
> be a rewrite of the wxWidget driver.
>
> As you can see there are a number of steps before this gets fixed.
>
> Phil
>
> -----Original Message-----
> From: "Arjen Markus" <arjen.mar...@deltares.nl>
> Sent: 08/10/2014 08:53
> To: "Phil Rosenberg" <philip_rosenb...@yahoo.com>; "Alan W. Irwin"
> <ir...@beluga.phys.uvic.ca>
> Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
> Subject: RE: [Plplot-devel] Testing on Windows (line endings for bashscripts)
>
> Hi Phil,
>
> Wouldn’t the non-threadsafety of Plplot only be a problem if you run Plplot
> routines from two different threads? If you can limit the calls to a single
> thread, it ought to be alright.
>
Hi Phil:
What individual tests become dependencies of one of the larger test
targets is determined in examples/CMakeLists.txt. I just
double-checked there, and it turns out the test_interactive target on
Unix platforms includes no wxwidgets tests for the reasons commented
in two stanzas of CMake code. Here is one of those stanzas for
reference:
if(NOT device STREQUAL "wxwidgets")
list(APPEND interactive_targets_LIST test_c_${device})
if(device STREQUAL "tk" OR device STREQUAL "ntk")
list(APPEND tk_targets_LIST test_c_${device})
endif(device STREQUAL "tk" OR device STREQUAL "ntk")
elseif(WIN32_AND_NOT_CYGWIN)
list(APPEND interactive_targets_LIST test_c_${device})
else(NOT device STREQUAL "wxwidgets")
message(STATUS "WARNING: The test_c_wxwidgets target can be run
independently on
the Unix platform, but it generates \"forced mousing\" screen
refreshes for the wxwidgets-3.0.0 case so it is temporarily
excluded from being a dependency of other more general interactive
test targets")
endif(NOT device STREQUAL "wxwidgets")
So what you should do when encountering an error that is going to take
a long time to fix (such as the wxwidgets segfaults you are
encountering on Windows) is you should comment out or drop the
list(APPEND interactive_targets_LIST test_c_${device})
command that is in the elseif(WIN32_AND_NOT_CYGWIN) stanza and replace
it with a suitable warning message. Remember to do this for the two
separate stanzas involving wxwidgets, and then you can move on to
other issues turned up by the test_interactive target which can be
treated the same way (bypassed with a WARNING as with wxwidgets) or
fixed (if the issue is a simple one).
Remember, the point of the test_interactive target is not to perform
all interactive tests (although it comes reasonably close). Instead,
the point is to perform all interactive tests that currently work on a
given platform such as WIN32_AND_NOT_CYGWIN so that we can quickly
identify regressions in the future if some interactive test quits
working on the given platform and also warn about any interactive
tests that are not included in the test_interactive target because of
bugs turned up by those individual tests. And similarly for the other
large test targets such as test_noninteractive, test_all_qt,
test_all_cairo, test_tcl, etc., that depend on other smaller
individual test targets.
With regard to the wxwidgets issue itself, I suspect the different
implementations of the wxwidgets library on Windows and Unix may be
playing some role here causing the different bad symptoms we see on
the separate platforms. However, it is also possible the forced
mousing that is required on Unix (i.e., the screen will only refresh
if the mouse is continually moved) is simply the way the thread safety
issue you have discovered on Windows is manifested on Unix. Anyhow,
in the long term when you are finally able to fix the thread safety
issue, it will be interesting to see if that forced mousing bug seen
on Unix goes away.
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
__________________________
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
