Hi Alan I have been trying to work through your semaphore code, but I'm afraid I just don't quite get it.
At the heart of this bug is the fact that receiveBytes() should be able to accept a timeout for waiting for the semaphore to unlock and instead of being void it should return the number of bytes it actually read. When I tried to implement this I just kept getting deadlocks because I'm not really sure how it all works. Can I also just check, in the end what was wrong with the previous comms that I put in place? Didn't we eventually find that the source of the delays was the random number generator for determining the name of the shared memory and nothing to do with the actual comms? On 3 October 2017 at 09:07, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >> >> It is good that you are doing some critical thinking about my bytes >> transmission logic this way. However, it appears you are referring to >> the case where there are two separate but simultaneous uses of IPC >> (one to send an array of data from core to viewer and one to send an >> array of data from viewer to core). > > Hi Alan > Actually I am talking about the opposite case. Both core and viewer > make a receive request. In both cases the receiveBytes function will > not return until the data is received, but the other party can never > send it because it is also sat in the receiveBytes function. > > Here what happens is the core sends a locate command and calls > receiveBytes waiting for a response. > > The viewer receives the locate command and flags this so that we > capture the next mouse click, however before that happens the timer > triggers the viewer to check for some more data, it calls receiveBytes > then sits waiting for data. But of course the core won't send any data > until it has received the locate data. > > The result is deadlock and the viewer hangs. > > The proper fix should be that there is an option in receiveBytes to > return immediately if there is no data to grab. This option should > always be used by the viewer to avoid both this kind of deadlock, but > also to avoid hangs when the core is very busy - don't forget that the > user program might be doing some very intense stuff in between > plotting commands. > > Phil ------------------------------------------------------------------------------ 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
