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 <sione...@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>
