[erlisp-devel] Re: Erlisp progress?

[Dirk Gerrits]

Eric Lavigne wrote:
> My understanding (regarding Erlang) was that if a process couldn't
> handle its own condition then it would kill itself (and children) and
> pass the condition on to its parent. If the parent can't handle it,
> then the parent dies also and passes the condition on to its own
> parent. This continues until either someone handles it or it reaches a
> process with no parent (in which case the user sees an error message
> and some restart options). This is far from the usual way of using
> conditions in Lisp, but I was under the impression that Erlang handled
> the situation in this way.

A parent process won't die when a child dies unless they are /linked/,
as far as I know.  It's links that determine process deaths, not who
spawned who.

Also, there's a flag to choose what will happen when a linked process
dies.  Either the receiving process dies too (which could in turn cause
other linked processes to die), or it gets a message in its mailbox,
which it can then handle any way it pleases just like every other kind
of message.

Furthermore, Erlang's "conditions" are just simple tuples, easily
transported over the network.  For Common Lisp that's simply not the
case.

> As for one process killing another, I believe you and Faré discussed
> this on soc-erlisp. 

Not really.  Faré just mentioned what came out of the discussion between
you and him on the issue.  Quote:

> Linking of processes is a very important feature of the Erlang
> programming model. The difficulty being that of killing a thread when
> it's in the middle of some observable side-effect. This require proper
> locking and/or proper recovery mechanisms (roll back or roll forward).
> I've discussed the issue with Eric. Basically, we can either refrain
> from killing outside of safe-points (notably invoked at Erlisp
> function calls), or we can require processes to hold a lock while they
> are doing any kind of non-thread-local side-effect.

And that was all that was said on the issue as far as I can tell.

> A RECEIVE command which looks only for system messages can be built
> into the message sending system. In this case, the process might
> continue using CPU time for a bit longer after getting an order to
> die, but next time it tries to send messages to other processes it
> will hit the system message first. This is only a problem if there is
> a long-running process which doesn't use the messaging system very
> often, and in that case it is an efficiency issue only. I can imagine
> more complicated systems that wouldn't have this efficiency issue,
> but the first version doesn't need to be perfect.

Yes, that would be the "safe-points" approach mentioned above.  Sure,
this would make a good first version.  I'm not quite sure how acceptable
it would be in the long run though.

> For SoC I just need process linking. A week still doesn't seem like
> enough, but I think it is at least possible.

Well, good luck, and let us know if you run into problems.  It's a lot
trickier than many would think, so I hope the aforementioned discussion
you had with Faré paid off.

> I will definitely continue with Erlisp after SoC. For now, though, I
> am more focused on a certain deadline :-)

Great. :)

- Dirk