Thanks I find the shared memory interesting and have their testcases working on the latest svn 863
but the guy saying they are dinosaurs ..... ;) https://lists.gnu.org/archive/html/bug-apl/2014-06/msg00258.html On Fri, 27 Jan 2017 19:50:26 +0100 Juergen Sauermann <juergen.sauerm...@t-online.de> wrote: > Hi, > > if you look into older versions (say, around SVN 340) of src/Svar_DB.cc of > GNU APL then you will > find examples of using shared memory. > > Before APs/APserver was introduced, GNU APL used shared memory to store the > data of shared > APL variables (⎕SVO and friends). At some point in time that shared memory > was replaced by the > process running APserver, which now owns the shared memory (and does not > share it anymore). > Variables in APserver memory are now accessed via signals sent over TCP. > > If I remember correctly then the reason for changing to APserver was that you > couldn't share memory between > different machines. With APserver you can share variables between APL > workspaces running on different > computers. > > Apart from that, I would say that if shared memory is a dinosaur then it is > an extremely fast one. But using it > properly requires a little experience in that field. At least a thorough > understanding of semaphores. > > /// Jürgen > > > On 01/27/2017 07:05 PM, enz...@gmx.com wrote: > > > sorry - i found the testcases/AP* but if there is any thoughts/comments > on this any one has - it would be appreciated > > I realize shared memory is considered 'dinosaur' > > > On Fri, 27 Jan 2017 10:53:21 -0700 > enz...@gmx.com wrote: > > Hi > > I have found a lot of discussion threads on shared memory - the switch from > /dev/shm/ dir to unix sockets etc > > is there some example code using the new method that someone could pass to me? > > I have a synapse library in fpc that can access sockets and wanted to see if > conversion of it to apl was beneficial (speed wise, code complexity wise etc) > > thanks > > > > >
