On 2017-02-06 23:52-0000 p.d.rosenb...@gmail.com 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 __________________________ ------------------------------------------------------------------------------ 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
