Hello, shenanig...@sonic.net writes:
> On 08/17/2015 10:15 AM, Max Rottenkolber wrote: >> On Mon, 03 Aug 2015 08:12:36 -0700, shenanigans-65eDfwRo+1xeoWH0uzbU5w >> 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(). >> I have to voice interest. I would love for a CL implementation to support >> lightweight threads. > > There was a successful IndieGoGo campaign for SBCL features in the > recent past, so might there be someone interested, willing and able to > pursue implementing something like this? > > This can be its own thing rather than any attempt at paying homage to > Erlang or BEAM vm: for me at least, it's about runtime performance and > avoiding the big gc hits by discarding an entire heap upon worker exit > but in a way that accommodates hundreds of thousands of concurrent > workers. Start small, and build from there. Erlang & BEAM address all > sorts of use cases for which a Lisp system wouldn't necessarily need to > be constrained-- and keeping it more Lispy anyway. > > > I personally would contribute a few thousand US dollars for such an > effort, as it's beyond my knowledge of SBCL internals at this time. > > Extending ECL or as a implementation-specific package for it might be > another option, but again, this is beyond my knowledge of its > internals. Could you elaborate a little on this? > > While I respect the various languages orbiting Erlang, I'd rather use > Common Lisp. > > Thanks, > -Daniel Regards, Daniel -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi