Re: [Bug-apl] shared memory

[enztec]

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 <address@hidden> 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, address@hidden 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
> address@hidden 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
> 
> 
> 
> 
>