On 2015-07-06 09:52+0100 Phil Rosenberg wrote: > Hi Alan - this is now slightly out of context as I found it in my > drafts folder unsent. > I can confirm similar odd timing results on my Centos machine. I did > have a couple of exit() calls in wxPLViewer, which to be honest was > just lazy of me. On was used to close the app when -np was used. I > have now replaced these both with clean exit methods. this ensures all > destructors are called and I can now say that at least as far as I can > tell on Windows the shared memory is _always_ released. It is > certainly released when the window is closed using -np. This is on the > viewer side. I presume the use of -np still gives a clean exit on the > console side and doesn't invoke any exit calls anywhere? > > Unfortunately the odd timings still persist. Note that the application > only asks for 1 MB of shared memory so even if not freed I wouldn't > have thought it would slow anything down really after just one run. > > I haven't got time right now to set up a decent debugging environment > on my Centos machine, but I will try to double check the shared memory > is released on that system as soon as I can.
Hi Phil: Thanks for confirming those odd time results for second and subsequent runs of the wxwidgets examples on CentOS, and I hope that you and Andrew also try the same experiment on more modern Linux platforms as well just to check whether the issue is due to an issue with mmapped shared memory for older Linux kernels (such as those for CentOS and Debian Wheezy) that has been fixed for modern Linux kernels (say those used for Debian testing and unstable and for the latest Ubuntu). Another question to consider is does this odd timing issue occur immediately for a fresh reboot or does the platform have to accumulate a relatively long uptime with lots of wxPLViewer use before the odd timing results appear? In the former case, the issue is unlikely to be due to some costly emergency response to some mmap resource exhaustion and will therefore be a lot easier to track down (assuming modern Linux kernels show the issue). For the case where freshly booted modern Linux kernels show the problem and normal debug methods cannot find the source of it pretty quickly, then I think it is time to implement a really simple mmapped shared memory example following your present IPC method. The client should loop through nmax different requests for double precision values from a server and sum those values. The server should respond to those requests by delivering 0., 1., 2., etc. The client can compare the computed sum of those numbers with the known nmax*(nmax-1)/2 sum to double-check the server is delivering the values properly. With such a simple mmapped shared memory example implemented (with nmax set at a large enough value so the example takes a second or so) then you can test for odd timing issues like above. If the simple example demonstrates that issue for a freshly booted modern Linux kernel, then the simple example will be a big help when preparing a bug report for the Linux kernel development team. (Note, I should probably be the one to present that bug report since I have fairly good contact with a RedHat employee that works every day on the Linux kernel, and from experience several years ago with a Linux kernel issue I was having back then he is very accommodating about running simple tests for the very latest Linux kernel.) Also, implementation of such a simple example of mmapped shared memory IPC should allow you to debug any excessive wait times in your IPC method that should never occur for such a flood of requests for double precision values from the client. 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 __________________________ ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
