Erlang style processes in Common Lisp
David Holz
david.holz at grindwork.com
Wed Aug 19 05:07:51 UTC 2015
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/
More information about the pro
mailing list