Hi Alan Just a quick email while I procrastinate, rather than start tidying from last night's festivities - happy new year by the way :-)
You are almost right regarding the ipc. But actually for most things it is a bit simpler than that. The shared memory has a small header area and then a data area which is set up as a circular buffer. The header includes a read pointer and a write pointer. Whenever the driver receives a command it simply adds the new part of the plplot buffer to the data area, then updates the write pointer. The viewer repeatedly checks the read and write pointers and if they are not equal then it reads the new data and updates the read pointer. In this model, the only time the driver should be waiting is if the buffer fills up and the write pointer catches up with the read pointer. Then the driver must wait for the viewer to update. Actually things then got a bit more complicated, because there are other things to deal with such as the cursor position requests etc. But that is the basic model. So in most cases the communication is only one way. Therefore semphores are generally not needed and named semaphores can be very slow - on Linux I think they involve creating a locked file - so I try to avoid them when possible. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> Sent: 30/12/2015 22:51 To: "PLplot development list" <Plplot-devel@lists.sourceforge.net> Subject: Re: [Plplot-devel] Linux wxwidgets inefficiency not solved On 2015-12-30 13:20-0800 Alan W. Irwin wrote: > That is, my mental model of the ideal IPC is the -dev wxwidgets code > launches a wxPLViewer application (WA) and the two processes set up > IPC between them. Then the IPC between the two processes is the one > with control goes about its business until it needs the other to > service a request. Then it simply writes needed data for that request > to a shared memory area and sends a specific signal to the other > process to deal with that data, and then that other process receives > that specific signal and deals with that data and continues until it > needs the other process to service a request. Thus, with this ideal > IPC model, the cpu is busy 100 per cent of the time either running > real code (not a wait loop) in either the device or WA. That is, when > either device or WA are waiting while the other is busy, they are > waiting for explicit signals from the other to proceed and are not in > some sort of inefficient sleep x amount of time and wakeup and check > for activity from IPC partner loop. Just found a useful illustrative example via google. Take a look at the "Unamed semaphore example" in <http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf> which uses POSIX semaphores to signal between two processes that are accessing the same POSIX shared memory. Naively, this looks quite efficient to me with no unnecessary simultaneous waits by the two processes since sem_wait just blocks until the other process is finished serving the request. I don't understand drivers/wxwidgets_comms.cpp at all, but I do notice you use sem_open, etc., there. Thus, it appears you are using a similar POSIX semaphore basis of method of control between the two processes that are accessing POSIX shared memory. If so, then I frankly cannot see how both processes would spend so much time simultanously waiting with completely idle cpu unless there is some issue with how you have implemented the use of semaphores. So maybe this would be a good time to carefully review that. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
