On 3 October 2017 at 22:01, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >>> 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. >> >> >> Hi Phil: >> >> Because you are having trouble understanding the transmitBytes and >> receiveBytes design, I think the best thing to do is for me to look >> closely at the deadlock scenario you have described previously to see >> if the current design answers it. And if it doesn't, I will modify >> transmitBytes and receiveBytes appropriately. But this all will take >> some substantial time on my part because I have other PLplot issues >> (such as the cross-talk between streams that some interactive devices >> show for example 14) on my plate right now. >> >> Meanwhile, you did say you had some sort of fix for locate mode >> which you (much earlier in the recent discussions between us) described as >> >>> I have made a quick couple of changes that makes locate work correctly >>> again with wxWidgets by simply halting checking for new data while >>> doing a locate, then starting again when locate is complete. > > Yes, plus a full fix for the old style comms. I have also realised > that I am not correctly filling in the state variable for the locate > info, so example 20 is still not quite working as it should. However I > am having some trouble capturing the mouse button release. Once I have > that worked out I will push the changes. > >> >> >> But you were reluctant to push those changes at that time, and I don't >> think you have done so since. If these changes do not involve the >> introduction of timed waits or modifications to transmitBytes and >> receiveBytes is there any reason to not push them? But if they do >> involve such changes (e.g., to work around the deadlock you think is >> there), then please don't push them and send me the patch instead to >> help educate me about that issue. > > Yes it's a workaround rather than a proper fix. There really does need > to be a timeout when the viewer checks for more data otherwise it > causes all sorts of problems with possible deadlocks and also just > unresponsive windows, i.e. resizes won't work and windows won't close > while the viewer is waiting for the semaphore. You can see the > deadlock by running example 20 with -nosombrero (you need this as > there is another problem that will be fixed by the commit I mentioned > above). You will find both sides of the communication hang. You can > also uncomment the #define WXPLVIEWER_DEBUG line in wxWidgets_dev, > then run x20c in a debugger - it will give you the command to run > wxPLViewer in another debugger instance so you can see the point at > which the hang occurs. Basically the core code is sat waiting for the > locate data and the viewer has carried on repeatedly checking for new > data so cannot actually collect the locate data.
I have just commited the workaround. But sadly it turned out not to be very reliable. I'm not sure why. I am now sometimes able to get past page 2 of example 20, but sometimes it hangs before I can leave and sometimes it hangs later in the sequence. The non-IPC3 method is currently working perfectly with locate. ------------------------------------------------------------------------------ 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
