Really good points Michel, thank you for describing so clearly! If we're talking solely about multiple picolisp processes, then there is built-in picolisp IPC for picolisp processes started by the same common parent process. Check out: (fork) (tell) (kids) (hear) and the functions in @lib/boss.l
There are also coroutines (co) and (task) / *Run @Lawrence: Still theorizing over theoretical properties? I recommend to do a little benchmark project or a little proof of concept of what you want to do. General discussion/research is good to get a rough overview, but will hardly give you an answer for a concrete case, then better do a prototype. And don't forget there is no golden language being the perfect tool for every person and every project, technical features of a language is just one property of many to take into account. -beneroth ----- Original Message ----- From: Michel Pelletier [mailto:[email protected]] To: [email protected] Sent: Tue, 5 Jan 2016 18:56:04 -0800 Subject: Re: picolisp and erlang in distributed/concurrent processing 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: https://github.com/aw/picolisp-nanomsg 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 other. https://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model 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. -Michel On Tue, Jan 5, 2016 at 5:50 PM, Lawrence Bottorff <[email protected]> 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 >
