On 2017-02-04 19:41-0800 Alan W. Irwin wrote: > So in the ideal case (where all steps below ultimately work and there > are no efficiency reductions due to any of these steps) the remaining > planned steps in this development effort for the > -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON case are as follows: > > 1. Make the current one-semaphore approach work with unnamed > semaphores. The last commit put essentially all the infrastructure in > place to support this further change so this change should be a simple > matter of replacing (for this case) the calls to sem_open and > sem_close with sem_init and sem_destroy, and the rest of the current > one-semaphore code should work as is along with the mutex and sleep > API calls required by this method.
Hi Phil: Thanks to your quick response to my C++ questions I have now (commit e705f7a) completed step 1 above (by simply passing the address of wsem as appropriate). As expected (since the same fundamental one-semaphore method is used in both cases) there is essentially no difference between results using -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON and -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF. So it is on to step 2 (below) for me. > 2. Move from the present one-semaphore approach (which necessarily > includes mutex and sleep activity) to the mutex- and sleep-free > two-semaphore model following the cmake/test_linux_ipc proof-of-concept > project. With regard to step 2. I am still trying to figure out why wxPLDevice::TransmitBuffer and wxPlFrame::ReadTransmission are currently so complex, and I hope they will be vastly simplified with the two-semaphore approach that was used in the proof-of-concept project cmake/test_linux_ipc. In that project there was a simple write loop to send _all_ the data using just the two semaphores to control the progress of the data transfer and a simple read loop to read all the data that was sent (again using the two semaphores to control progress of the data transfer). So that simple approach is what I hope to implement for step 2. More later as I get deeper into step 2. 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
