Dear Eric, haven't had news from you in a while. How is your Erlisp progress? Is everything going fine? Are there stumbling blocks?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] ...so that IBM Java envangelist tells me "nothing spread as fast as Java", to which I answer: "crack!"...
Dear Eric, haven't had news from you in a while. How is your Erlisp progress? Is everything going fine? Are there stumbling blocks?
Dear Faré,
One issue is that I never used conditions before. I read a bit about them in PCL. What I am imagining is creating a default condition handler which catches any unhandled conditions and sends them as messages to the parent thread (then arranges for its own thread and its children to be shut down). Maybe the handler could be implemented by replacing (make-thread thunk) with something like this (make-thread (lambda () (default-condition-handler thunk)))
Does this sort of thing work? Can I throw a condition, catch it, send it as a message, then throw it again in another process?
There is also a need for each process to keep track of its parent and any children. This should be simple, but it is not yet clear to me how to do it.
Another issue, of course, is time. Classes have started again, and there is only a week left for SoC. I am going to keep trying until the end, but this is looking very hard.
I have been reading the Erlisp source, PCL, and Concurrent Programming in Erlang, but now it is definitely time to get back to coding.
Eric
Hi Eric.
Eric Lavigne wrote:
One issue is that I never used conditions before. I read a bit about them in PCL. What I am imagining is creating a default condition handler which catches any unhandled conditions and sends them as messages to the parent thread (then arranges for its own thread and its children to be shut down). Maybe the handler could be implemented by replacing (make-thread thunk) with something like this (make-thread (lambda () (default-condition-handler thunk)))
Does this sort of thing work? Can I throw a condition, catch it, send it as a message, then throw it again in another process?
Well if you're going to do distributed programming with READ/WRITE for serialization you can definately not send condition objects in a message.
Also, I don't know how one could reraise the condition in another process. I mean, if RECEIVE sees such a "condition message" it could do a raise, but then a linked process would only be killed the next time it did a RECEIVE.
There is also a need for each process to keep track of its parent and any children. This should be simple, but it is not yet clear to me how to do it.
Another issue, of course, is time. Classes have started again, and there is only a week left for SoC. I am going to keep trying until the end, but this is looking very hard.
Oh gee, one more week only? Then getting process linking and distribution done for the SoC is definately not realistic. You are of course more than welcome to continue working on Erlisp after the SoC has ended, if you want to, and time permitting.
I have been reading the Erlisp source, PCL, and Concurrent Programming in Erlang, but now it is definitely time to get back to coding.
Okay, let us know how it goes. :)
- Dirk
Does this sort of thing work? Can I throw a condition, catch it, send it as a message, then throw it again in another process?
Well if you're going to do distributed programming with READ/WRITE for serialization you can definately not send condition objects in a message.
Also, I don't know how one could reraise the condition in another process. I mean, if RECEIVE sees such a "condition message" it could do a raise, but then a linked process would only be killed the next time it did a RECEIVE.
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.
As for one process killing another, I believe you and Faré discussed this on soc-erlisp. 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.
Oh gee, one more week only? Then getting process linking and distribution done for the SoC is definately not realistic.
For SoC I just need process linking. A week still doesn't seem like enough, but I think it is at least possible.
You are of course more than welcome to continue working on Erlisp after the SoC has ended, if you want to, and time permitting.
I will definitely continue with Erlisp after SoC. For now, though, I am more focused on a certain deadline :-)
Eric
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
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
Should it also be possible to link processes which do not have a parent-child relationship?
I'm pretty sure this is possible. There is a function for linking processes.
Are links two-way (if either dies the other will be affected)?
Links are bi-directional in Erlang. From this Lambda the Ultimate post on Termiate, a Scheme distributed framework:
http://lambda-the-ultimate.org/node/view/841
"Termite links are unidirectional but Erlang links are bidirectional. There seems to be consensus in Erlang-land that it would be better to have unidirectional links, though you still need to make sure that bidirectional link-pairs can be created "atomically" enough (maybe easy)."
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?
Multiple linked processes are allowed. For example a parent that spawns 5 worker processes. All worker processes need to know if the parent dies so they can die gracefully.
Chris.
"Termite links are unidirectional but Erlang links are bidirectional. There seems to be consensus in Erlang-land that it would be better to have unidirectional links, though you still need to make sure that bidirectional link-pairs can be created "atomically" enough (maybe easy)."
Unidirectional and bidirectional are equally easy to implement, and unidirectional are more flexible (bidirectional is just a one-line function away), so I'm inclined to follow the Termite example here.
Does Erlisp have process dictionaries or some way that I could store information on a per-process basis? There must be something, since each process has its own mailbox, but I haven't figured out how this is done.
Eric
Eric Lavigne wrote:
"Termite links are unidirectional but Erlang links are bidirectional.
Unidirectional and bidirectional are equally easy to implement, and unidirectional are more flexible (bidirectional is just a one-line function away), so I'm inclined to follow the Termite example here.
Well atomically creating the two unidirectional links for the bidirectional case doesn't seem completely trivial to me.
I agree about doing things the Termite way though.
Does Erlisp have process dictionaries or some way that I could store information on a per-process basis?
Processes are instances of (a subclass of) the PROCESS class. You can just give the PROCESS class extra slots.
There must be something, since each process has its own mailbox, but I haven't figured out how this is done.
That would be the MAILBOX slot.
- Dirk
On 9210 day of my life Eric Lavigne wrote:
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.
CL conditions are not Erlang exception. Is it worth to imitate Erlang's behavior in exception handling?
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.
CL conditions are not Erlang exception. Is it worth to imitate Erlang's behavior in exception handling?
-- Ivan Boldyrev
I have no experience with Erlang exceptions, and not so much experience with CL conditions either (I am new to the language), so it is hard for me to judge which is better. My feeling, though, is that we should start by following a simple model, such as Erlang, that has succeded in our area of interest (concurrent programming), then try changing things from that point. I suspect that it would be difficult to experiment with new ideas before we have a working system. The CL model probably has something to contribute here, but it is not clear how it would be extended to multi-thread/multi-node situations.
Eric
-
Chris Double -
Dirk Gerrits -
Eric Lavigne -
Faré -
Ivan Boldyrev