Hi Alan That seems reasonable. I'm not sure what the benefits are though. Should the new way be quicker?
In terms of the overall complexity here are some of the things I found while setting up the current system that each made the system more complex than I initially envisaged. I imagine you will come across many of these too. The reason that I went for a circular buffer is that data can continuously be being sent even while the reader is reading. That is until the writer catches up with the reader. In a simple restart-from-the-beginning buffer like you seem to be proposing the sender must wait until the reader has read all the data from the buffer before it can send more data. In fact I have a feeling that the system as I have it now makes little or no use of the actual semaphores and just uses flags in specified locations in the shared memory. I would have to look through the code properly to check. Don't forget also that while waiting for new data the semaphore cannot block indefinitely. To do so would hang wxPLViewer or the sender software. I think also there is no way to tell if a page is finished or whether there is more data to come. Therefore you must use non- blocking semaphores and poll them on regular intervals. If you want to do two way communications you will need two areas of shared memory, one for each direction, otherwise you will likely have a race condition for which process will write next. As it happens, like you said the transfer is almost all one way, with just a small amount being returned. So I just allocated a small portion of the shared memory to represent a struct to hold some specific returned information. I'm doing this from memory, but I think it would work like this for the case of getting text size. Sender zeros the flag which indicates a text size is available. Sender sends a message to the Viewer saying it wants a text size and with the string it wants sizing Sender starts checking the flag to say that the text size is available. Viewer receives the message requesting text size Viewer determines the text size and writes it to the location in shared memory reserved for text size Viewer sets the flag which indicates text size is available to 1 Sender sees the text size flag it one Sender reads the text size from the location in shared memory that is reserved for text size. The same is basically true for getting position information for pllocate calls. But there is a pause on the Viewer side while it waits for user input. Of course the alternate is to set up a totally generic symmetric system, I'm not sure if one is easier or faster. I guess all these things contribute to the complexity of the code that is there, but I'm not sure that it is more complex than necessary. I'll be interested to see how your setup differs :-) Phil On 7 February 2017 at 02:01, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > 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
