Hi Alan
Not exactly sure what you mean by complex? It is not always possible to send
all data, as the shared memory is finite size and therefore the data to be sent
may be bigger than the shared memory. The reading and writing is therefore set
up as a ring buffer, so when the writing gets to the end of the memory it
begins writing again at the beginning. Of course if we write faster than we
read (entirely likely because as we read we may be rendering, which is
expensive) then the writing will eventually catch up with the reading and would
“lap it”. There is therefore extra logic to avoid that. Then there are some
features that require two way comms such as getting text size and getting mouse
positions and key presses for pllocate so there is extra logic for these. All
this is set up with a series of flags in the memory. And a named semaphore if
memory serves correctly.
I presume it's this named semaphore and/or memory flags that you intend to
remove?
Phil
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 06 February 2017 21:31
To: Phil Rosenberg; PLplot development list
Subject: Re: [Plplot-devel] Recent progress with wxwidgets IPC
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
