I did something similar several years ago for Butterfly, where I pre-instantiate a pool of threads into the “stable”, and utilize a Grand Central Dispatch (real and / or simulated) to run various jobs. No sense killing the horses after they run the racetrack.
But this is still a far cry (a few dozen threads) from what Erlang and CML provide (numbering in the thousands). - DM > On Aug 3, 2015, at 12:46 PM, Faré <fah...@gmail.com> wrote: > > On Mon, Aug 3, 2015 at 3:36 PM, Attila Lendvai <att...@lendvai.name > <mailto:att...@lendvai.name>> wrote: >>>> 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. >> >> well, Nikodemus had some plans for green threads for SBCL and it >> didn't sound like a rewrite. >> >> and adding first class heaps would be a very useful addition with or >> without any of the other erlang stuff. i don't know how hard that is, >> but i assume it should be rather simple if the responsibility is >> pushed over to the user to make sure that there are no dangling >> pointers after destroying a heap. >> >> or am i missing something? >> > Not Common Lisp (yet), but Racket has custodians for first-class > resource allocation pool, and all kinds of concurrency primitives. > Since it's a programming language designed to implement other > programming languages on top of it, it would make a great basis for a > "new" common lisp implementation. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• > http://fare.tunes.org <http://fare.tunes.org/> > There are a thousand hacking at the branches of evil > to one who is striking at the root. — Thoreau