Erlang style processes in Common Lisp

David McClain dbm at refined-audiometrics.com
Mon Aug 3 16:01:22 UTC 2015


It would be great to have such rapid fire threads. In addition to Erlang style, it could also support Concurrent ML style and Reppy Channels. Threads would be able to form spaghetti stacks and be quickly pared when dead. Could do a lot more speculative threading.

But that really does sound like a redesign of CL.

(I’m one of the authors of an Erlang-like system in Lisp, called Butterfly. The Scheme guys have one called Termite.)

- DM


> On Aug 3, 2015, at 8:34 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> 
>> Creators of Erlang have a Lisp background, and one feature of the Erlang 
>> VM (BEAM) that I'd like back-ported into Common Lisp is their process.
>> 
>> An Erlang "process" is cheap to create, cheap to destroy, cheap when 
>> blocked, and upon exit performs bulk gc of its allocated memory; e.g., 
>> munmap().
>> 
>> Handling tens of thousands of requests per second per node isn't 
>> uncommon, and these often have *several* workers per request or 
>> connection: hundreds of thousands of processes.  Under such scenarios, 
>> anything less than this approach to lightweight processes might suffer 
>> from stalls during long gc runs that would be avoided or significantly 
>> reduced under Erlang's model.
>> 
>> 
>> How might we get equivalent cheap ephemeral processes into a 
>> contemporary Common Lisp implementation?
> 
> In short, you need to write from scratch a new CL implementation. Current ones are not designed with the Erlang constraints in mind.
> 
> -- 
> Stelian Ionescu a.k.a. fe[nl]ix
> Quidquid latine dictum sit, altum videtur.
> http://common-lisp.net/project/iolib <http://common-lisp.net/project/iolib>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20150803/32f68123/attachment-0001.html>


More information about the pro mailing list