[erlang-in-lisp-devel] Using fork

[Faré]

My plan for Erlang-in-Lisp was to start with fork as the primary
method for spawning language-level processes using a "one OS process
per Erlang process" model indeed. The reasons follow.

1- Yes, the performance of fork doesn't scale and thus severely limits
the applicability of the actor paradigm, but scaling can be achieved
later by other means: portable lisp-in-lisp green threads (as in the
Tube or philip-jose), or implementation-specific green threads.

2- fork is portable (to any unix/cygwin), and provides desirable
isolation properties that would require a large number of hours of
debugging to enforce using other methods (especially when Lisp
implementations and libraries were not designed to be thread-safe).
Yes, these other methods will have to be implemented eventually, but
fork-based concurrency will allow us to have a reference
implementation by then that can help discriminate between
implementation bugs vs application bugs.

3- Fork-based concurrency also provides for very desirable isolation
from bugs in third-party libraries, and for native compilation of lisp
code without an intermediate translation layer - two properties that
we will certainly want to preserve even when we have other
implementation strategies available for multiprogramming.

4- last but not least, fork-based concurrency seems like it's the
easiest, cheapest and fastest way to get an initial working system.

So no, fork-based concurrency not the be-all end-all of
Erlang-in-Lisp, but I really think it's the best way to start.

Once we have a simple working implementation that doesn't scale, we
can add new strategies:
* lisp threads as in cl-muproc, whether the underlying lisp uses
system threads (as SBCL does) or green threads (as CMUCL does),
* a portable but very slow meta-programming green threads as in
philip-jose (uses arnesi's slow ((lisp with continuations) in lisp)
interpreter), that should allow migration of processes (within some
restrictions).
* a similar portable but less slow method using a lisp-in-lisp
compiler instead like the one in Screamer, which might not allow for
migration (or might, if we use the same tricks as the Tube).
* pushing the code to a remote Erlang implementation (whether
Erlang-in-Lisp or plain Erlang), if it doesn't use any of our
Lisp-specific "extensions", but only things available with say LFE.
* any other method du jour.

Hopefully, we can make it easy to select what strategy we use to spawn
any particular language-level process.

(Hum, such design rationale should probably be pushed  into a design
document included with the code.)

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
I don't program enough to be called a "programmer", and I don't non-program
enough to be called a "non-programmer". So I'm a non-non-programmer, which,
in intuitionistic logic, is weaker than a programmer. -- Faré



2008/5/18 Robert Virding <rvirding at gmail.com>:
> I saw the reference to fork in the earlier message. Seeing I have come in a
> little late you will have to excuse my asking. What do you intend to use
> fork for in erlang-in-lisp? Erlang processes? Many Erlang processes can
> generate many processes.
>
> Robert