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@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