Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2017-02-05 03:41:28
|
Hi Phil: You have probably noticed my recent push of commit 3da0c90. That commit contains my recent (fairly small amount of) wxwidgets IPC code progress. The unnamed semaphores method requires the shared memory buffer be a struct (so that the buffer contains room for the required semaphores as well as the data array). So all I have done so far is to adjust the IPC code so it can use a struct for the shared memory, but at least this commit tests without issues. N.B. the new IPC code is only exercised if the experimental cmake option (which defaults to OFF) is set to ON using -DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON. And conditional compilation will be used a lot for this development project. So for the Windows case the code that is compiled should be completely unaffected by any of my changes, and for the non-Windows case by default the OLD IPC method will be preserved and used unless and until the new IPC method for that case is at least as efficient and reliable as the old one. So in the ideal case (where all steps below ultimately work and there are no efficiency reductions due to any of these steps) the remainng 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. 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. 3. Implement a two-semaphore version of (2) that uses named semaphores instead of unnamed semaphores (because not all POSIX systems support unnamed semaphores). So this version should differ from 2 only by a few lines of code (which are already conditionally in place) to use sem_open and sem_close rather than sem_init and sem_destroy. N.B. like (2) this approach should also not require any use of mutex or sleep API. 4. Implement a build system change to test for unnamed semaphore functionality and use approach (2) if that functionality is available but otherwise use approach (3). This should allow us to drop the present one-semaphore approach that is used in the non-Windows case. In sum, my work is cut out for me, but at least I have made some initial progress toward the above goals, and I am beginning to get a bit more comfortable with C++. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2017-02-06 21:31:21
|
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 __________________________ |
|
From: <p.d...@gm...> - 2017-02-06 23:52:24
|
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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2017-02-07 02:01:43
|
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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2017-02-07 13:51:48
|
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...@be...> wrote: > 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 > __________________________ |
|
From: Alan W. I. <ir...@be...> - 2017-02-07 20:52:03
|
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 __________________________ |
|
From: <p.d...@gm...> - 2017-02-07 22:03:10
|
Hi Alan It'll definitely be interesting to see the differences. I wasn't trying to put you off, just hoping you can get a boost from the things that i learnt as I went along. That was the first time I'd tried ipc locally, although I did some one way network stuff years ago. It did turn out to be more difficult than I expected, especially once I realised there needed to be some 2 way comms. The only thing about sending amount, yes you are correct about the amountToCopy variable, but that is for exactly one transfer. However, i don’t think there is a reliable end of page command so you can't store up commands and send them all in one go when the plot is complete. Also the viewer never knows if the page is complete so must always keep rechecking for new data. Phil Sent from my Windows 10 phone From: Alan W. Irwin Sent: 07 February 2017 20:51 To: Phil Rosenberg Cc: PLplot development list Subject: Re: [Plplot-devel] Recent progress with wxwidgets IPC 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2017-02-08 04:49:59
|
On 2017-02-07 22:03-0000 p.d...@gm... wrote: > Hi Alan > It'll definitely be interesting to see the differences. I wasn't trying to put you off, just hoping you can get a boost from the things that i learnt as I went along. That was the first time I'd tried ipc locally, although I did some one way network stuff years ago. It did turn out to be more difficult than I expected, especially once I realised there needed to be some 2 way comms. > The only thing about sending amount, yes you are correct about the amountToCopy variable, but that is for exactly one transfer. However, i don’t think there is a reliable end of page command so you can't store up commands and send them all in one go when the plot is complete. Also the viewer never knows if the page is complete so must always keep rechecking for new data. Thanks, Phil. I will keep everything you have said in mind, and I will likely have some specific questions later for you as I gain a deeper understanding of all the constraints on the wxwidgets IPC. 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X