Re: [Plplot-devel] Recent progress with wxwidgets IPC

[Alan W. I. <ir...@be...>]

On 2017-02-06 23:52-0000 p.d...@gm... wrote:

> 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.

Hi Phil:

To get a preview of what I mean by implementing an approach that is
simpler than the current one, I suggest you take a look at the code in
cmake/test_linux_ipc.  There, the shared memory buffer size is
relatively small, that buffer is _not_ a circular buffer, and
typically the amount of data to be transmitted >> shared memory buffer
size.  The data are split up into chunks that fit into the buffer on
the sending side and those chunks are assembled on the receiving side
under the control of two semaphores.  The result is an efficient
transfer of the entirety of what can be an extremely large amount of
data (25MB in one test) between sender and receiver with relatively
simple code and relatively small shared memory buffer.

My current plan is to have a generic function "send" for sending a
generic array of bytes and a generic function "receive" for receiving
that array where those functions contain all the details of the
two-semaphore method for transmitting and receiving a generic data
array.  Then higher level code would create an array to be sent or
received and then they would use this send/receive API to transfer
those arrays.  Of course, the usual case is that -dev wxwidgets
normally would call the "send" API and wxPlViewer normally would
normally call the "receive" API, but when those roles are reversed
(e.g., when transmitting back the physical size of displayed text
strings), then wxPlViewer will be calling the "send" API and -dev
wxwidgets will be using the "receive" API.

> I presume it's this named semaphore and/or memory flags that you intend to remove?

I am definitely going to keep named semaphores (see step 3 in my
original plan where a small change to the two-semaphores approach
should change that approach from two unnamed semaphores to two named
semaphores.) This variant of the two-semaphores method is necessary
because some lame proprietary Unix systems (e.g., Mac OS X) only
return a "not implemented" error when attempting to use unnamed
semaphores.

I still don't understand enough about the current code to answer the
memory flags part of your question, but the only thing I intend to
change is from the current circular buffer/one semaphore approach to
the above two-semaphore approach for sending and receiving data with
the plan being that -dev wxwidgets will both send and receive data and
similarly for wxPLViewer.

And, of course, I will leave the IPC approach used for the Windows case
completely untouched.

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
__________________________