On 2017-02-26 22:51-0800 Alan W. Irwin wrote: [....] > Therefore, I plan to turn the current two-semaphore approach into a > three semaphore approach where m_wsem and m_rsem will continue to be > used for the details of a complete transfer of an array of bytes, but > an additional m_tsem semaphore (where "t" stands for transfer) will be > used so that only one such transfer of bytes can be done at a given > time. As far as I can tell, this change means I can completely drop > the moveBytesReaderReversed variant of moveBytesWriter and the > moveBytesWriterReversed variant of moveBytesReader which is a really > nice simplification. Furthermore, I plan to rename moveBytesWriter to > transmitBytes and moveBytesReader to receiveBytes where both > transmitBytes and receiveBytes will be used by either of -dev > wxwidgets or wxPLViewer as needed depending simply on the direction of > data flow. > > The additional m_tsem semaphore will be initialized to 1; > transmitBytes will start by calling sem_wait on that semaphore and > will end by calling sem_post on that semaphore. That simple changes > means if wxPLViewer uses transmitBytes to send data that is received > by -dev wxwidgets with receiveBytes, and then -dev wxwidgets follows > up by calling transmitBytes to send data back that is received by > wxPLViewer with a call to receiveBytes, that second use of > transmitBytes will be halted by the sem_wait until that first use of > transmitBytes is entirely completed, i.e., any call by either side of > the IPC connection to transmitBytes cannot possibly race with a > previous call to that routine by either side. > > Anyhow, I like this pure semaphore way to avoid the race condition > much more than the 10 ms sleep, and I hope to get it completely > implemented tomorrow.
Hi Phil: Done as of commit c39f93d. As a result, once again I think I am at a stage in this -DPL_WXWIDGETS_IPC2=ON development where all further changes will be small ones so I encourage you to look at this code in anticipation that you will want to reorganize it along the lines you discussed before. The current status is all examples work (i.e., there are no obvious run-time errors and there are no rendering issues other than previously known ones for the -DPL_WXWIDGETS_IPC2=OFF case) other than 02 and 14 (where an exception is consistently thrown by wxPLViewer for currently unknown reasons), and examples 01 (in locate mode) and 20 (because interactivity not implemented yet). I next plan to work on the example 2 issue. 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
