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