Hi Phil: You make a lot of points about some uncertainties in what I propose to do. And I do agree there are such uncertainties. So this is definitely a "show them the code" moment. At worst, I will strip it all out again because it will turn out to be complex and slow. But it could be significantly less complex (no polling!) and just as efficient or better. So we will see.
Further discussion below about that "no polling" point. On 2017-02-07 13:51-0000 Phil Rosenberg wrote: [...] > 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. True, but neverthless the mini-project demonstrated this was an efficient method of moving many MBytes at one go since effectively the only costs (assuming overheads are small) are a memcpy of those bytes on the sending end and a memcpy of those bytes on the receiving end, and (this is the important point) without any polling at all! Note, in principle for GigaHertz machines a 1 GByte memcpy should only require 1 second or so. So we are discussing really small inefficiencies here so long as the size of the buffer is large enough to make the overheads of the method (the overhead of setting up the transfer of control to the memcpy routine for each chunk, and the overhead of checking semaphores as each chunk is passed). So I would expect the method would be inefficient for really small buffer sizes (such as 100 bytes or so). But, for example, I was already getting quite efficient results with a buffer size of just 1K (!) so I don't think the overheads of this two-semaphore method are that big a deal. Of course, if you add polling to the mix, then that would introduce a lot of efficiency concern. But there is no polling needed or used in this mini-project so that is why it is efficient, and I believe I can avoid polling as well for the wxwidgets IPC method, see below. [...] > 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. My assumption is the sending side knows exactly how many bytes it needs to send. And my preliminary analysis is that is exactly what the present code calculates with the amountToCopy variable in wxPLDevice::TransmitBuffer. So with that assumption (and as demonstrated by the mini-project) there is no need for non-blocking semaphores or polling if you use the two-semaphore method. Of course, this line of reasoning completely falls apart if amountToCopy does not do what its name implies so please let me know if there is some case where that calculation is unreliable. My efficiency test results for the case where the -np option is not used show the inefficiences of the present wxwidgets IPC are negligible compared to wxPLViewer taking a long time (30 seconds for example 8) to render the plot while other interactive devices take the order of a second for this same task. Most of this large time interval occurs after -dev wxwidgets is completely finished so IPC ineffiency cannot be the source of this wxPLViewer inefficiency for cases like example 8 where large numbers of graphical elements are being plotted. Therefore, from this evidence you do have the polling interval used in the present one-semaphore method tuned up fairly well (at least for typical PC hardware). So my fundamental goal here is making our wxwidgets IPC a lot simpler for POSIX systems by eliminating the polling and the rest of the circular buffer logic for that case. I am hoping for some noticeable improvement in efficiency due to this, but I am not counting on anything showing at all in that regard until at least the non-IPC inefficiency of wxPLViewer is addressed. In sum, it is "show the code" time. That is, it is pretty clear what I have said above has speculative elements and similarly for any further replies you make (unless you know of some cases where amountToCopy is definitely unreliable). So my focus from now on will be to continue my project of implementing the two-semaphore method for wxwidgets IPC. Once I have completed that implementation, we should evaluate that code and obviously if it is simpler and there is at least no drop in efficiency we should adopt it but otherwise not. 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
