This is an interesting question that I have a few thoughts on.

First, is that picolisp is so "light" and has such a minimal memory
footprint, that it's easy to use multiprocessing to many picolisp processes
running on a machine, or a in a container.  Multiprocessing has a
reputation of being slow and expensive, but that's not really my experience
on Linux.  One the advantages I believe is that the entire interpreter can
pretty much fit in processor cache, and all processes benefit.

Forks are nice in that they share nothing, so you need some kind of share
nothing IPC.  The awesome aw wrote some nanomsg bindings for picolisp that
do the job very well:  You can also
use mmap simply enough to share memory between processes. This provides you
with all the parts you need to undertake all kinds of "actor" like patterns.

Erlang, Elixir, and Go all use a concurrency technique called Communicating
Sequential Processes (CSP).  This uses an explicit, synchronous "channel"
abstraction to pass messages between processes and define rendezvous
points.  Processes talk on channels instead of explicitly named actor
endpoints.  As this link points out, there are a lot of overlap in
functionality with actor models, and they can both easily emulate each

Nanomsg kind of give you the best of both worlds, with synchronous and
asynchronous passing using either the actor abstraction or "channels" using
various routing policies (pub/sub, many to many, surveying, etc.)

My 2c.


On Tue, Jan 5, 2016 at 5:50 PM, Lawrence Bottorff <> wrote:

> If Erlang is a perfect 10 (or not!) in the world of distributed,
> concurrent, load-sharing networked interoperable (etc., etc.) software,
> what does picolisp bring to the table? What can I do along these lines in
> picolisp? Erlang allows a node to have thousands of "light' processes. How
> does picolisp do this?
> LB

Reply via email to