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