[erlisp-devel] Re: Erlisp progress?

[Eric Lavigne]

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

Would it be appropriate for linking to be controlled by a :linked
keyword passed to the process spawning function? Should it also be
possible to link processes which do not have a parent-child
relationship? Are links two-way (if either dies the other will be
affected)? If a process dies, is it possible that kill signals will be
sent to more than one linked process at a time, or is there ordinarily
just one linked process that would be affected?

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

Providing two behaviors, kill or send message, doesn't sound too hard.
I think I will start by implementing the send message version, then
modify it to respond to such a flag. Of course, getting to the point
of providing even one of those behaviors could be tricky.

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

Fortunately, I can wait until next week to think about this issue :-)
Perhaps there will be an erlisp-condition class which will be a bit
easier to send via network.

Eric