[erlisp-devel] Re: SoC status update please

[Eric Lavigne]

> > CMUCL integration is complete.
> Great. Do you have process kill working in CMUCL, SBCL, Allegro, in a
> way that is safe wrt locks and that propagates along the process tree?
> That's a major feature required of an erlang implementation.

I have not done any work on process killing. As far as I know, it is
not a part of ErLisp right now. This will definitely require a
kill-thread function in compatibility.lisp. Beyond that I'm not sure
how to procede. Manually calling kill-thread? Automatically calling it
following a time-out? Also, I would like to give each process the
responsibility for killing its child processes, but if it's being
killed because it is no longer responsive then that won't work... I
would like to see some discussion on this topic in erlisp-devel
because I have no experience with such situations.

> 
> This leads me to wonder how they do a reliable detection of a remote
> node being dead, as opposed to the communication channel being down --
> and how they cope with a mistake between the two. Surely the point is
> tackled somewhere in some Erlang documentation...

Best I can think of is for the node itself to be represented as a
process whose only job is communication with the outside world. Since
the user won't control this process directly, it should be possible to
make it fairly durable so that we can assume it is alive. *crosses
fingers*

> 
> > Next up is CLisp.
> I don't think clisp has a complete threading implementation yet. Does
> it? If it doesn't, then it might be time to begin a distributed
> implementation -- and to fork clisp processes as a way to build new
> threads.

It looks like CLisp threading is very much a work in progress. I
didn't research this well enough in advance. Forking CLisp processes
is a nice idea, but we might be better off just letting it go until
CLisp has better thread support. The original reason for including
CLisp was so that Windows users would have access to ErLisp. Allegro
support solves that problem well enough for now.

So what next? Dirk, is ErLisp already have some sort of slot waiting
for process-linking code? Or will we be designing something from
scratch? I'm thinking that my next step is to read Faré's thesis
again. A robust distributed process management system does not sound
like an easy task.

Eric

-- 
http://plaza.ufl.edu/lavigne/
http://www.lispnyc.org/summerofcode.html