Erlang style processes in Common Lisp

[David Holz]

On 08/18/2015 08:24 PM, shenanigans at sonic.net wrote:
> 5. As with Erlang/BEAM: when sending messages across cores, *copy* 
> rather than share data for better cache locality.  Of course, the 
> Lispy approach would probably be to allow copying *or* sharing, and a 
> thin package on top of something like SBCL's sb-concurrently (with an 
> optional parameter to override) could enforce the recommended 
> approach. Caveat below.

One of the larger issues I had with Erlang was that you couldn't sic a 
bunch of threads on analyzing or searching immutable multi-GB raw data 
structures (not ETS entries, nor hacking around with byte blobs).

My ideal layout would involve per-process heaps, with the option to 
either cons into or copy into the immutable shared heap.  I believe 
collecting a shared add-only immutable-data heap in this form might not 
require stopping the world.  As was mentioned elsewhere, however, 
designing around immutability advantages does venture further away from 
Lisp's style.  Splitting memory into per-process heaps, shared immutable 
heap, and a shared mutable stop-the-world-to-GC heap might be going a 
little overboard, especially since the allocation/copy style generally 
has to be declared by the human.


-- 
David Holz
Director, Grindwork Corporation
http://www.grindwork.com/