Erlang style processes in Common Lisp
Daniel Kochmański
daniel at turtleware.eu
Tue Aug 18 06:09:58 UTC 2015
Hello,
shenanigans at 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
More information about the pro
mailing list