[erlang-in-lisp-devel] Re: Erlang in Lisp

[Faré]

(oops, I initially sent this answer only to Matt)

1- There are several semi-portable posix libraries for CL. Osicat and
IOlib are two of them. I happen to like IOlib, or at least think it's
a good platform to start from and hack further.

2- as for fork, yes, you should start with just a simple CL-based
wrapper to posix fork, and build around it.
 a- see however how in philip-jose I provide (at least in SBCL) a
mechanism to proactively GC before you fork to avoid an early GC in
the child.

3- the purpose of my heavily-frobbing fork was to provide a portable
way to fork-and-exec even when you can't control the GC.
 a- If a GC happens in the child in between the fork and the exec, the
result may be serious lossage, especially if the parent had multiple
system threads running. It is important then to frob and exec
"atomically" with respect to the Lisp heap.
 b- This isn't necessary for Erlang-like programming, only for CLSH
shell-like activity.

4- writing a portable "run-program" however is a good way to test the
(OS)process-tracking and fd-frobbing mechanisms.
 a- such a step I think is essential before we attempt to implement
fancy communication protocols between processes.
 b- Having all the bells-and-whistles of my attempted frob-and-fork
implementation is not necessary, and a first pure-lisp attempt is
probably preferrable

In short, start simple. If you don't understand why I (or someone
else) wrote some code in philip-jose or some other code, then it is
good to
 a- start by trying without the complexity (maybe doing things better
indeed, or maybe learning why and how the complexity has to be added)
 b- inquire (as you just did) why the complexity was added.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
When your hammer is C++, everything begins to look like a thumb.
       -- Steve Hoflich on comp.lang.c++


2008/5/18 Matt Bone <thatmattbone at gmail.com>:
> Ok, so I've been getting up to speed on my systems programming in
> common lisp.  I've actually been a bit surprised that there is no
> portable posix interface (though it shouldn't be too hard to make the
> things we're interested in work on various implementations).
>
> As far as pulling in the fork stuff from philip-jose, I've been
> screwing around with a lot of different things.  If it's alright with
> everyone I think I'd prefer to abandon the C file and just use
> implementation specific posix calls (like sb-posix:fork) when
> available and CFFI when not.
>
> To be honest I'm still not understanding how far we need to take the
> fork mechanism.  Are we trying to match, for example, the features in
> SCSH so this can be a useful standalone component?  Or is this just
> the concurrency mechanism we're looking to use as a starting point (if
> so, I have a few other questions/ideas that I'll need to
> ask/consider).
>
> I'll be away at a conference to present a paper tomorrow and tuesday.
> After that, all my non-SoC obligations are complete until the fall.
>
> --matt