From lavigne.eric at gmail.com Sat Aug 6 21:29:43 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Sat, 6 Aug 2005 21:29:43 +0000 Subject: [erlisp-devel] local nodes, how many? Message-ID: <51e1bc3005080614292b4b276f@mail.gmail.com> These lines are in erlisp/src/node.lisp: (defvar *current-node* (make-instance 'local-node)) (defun current-node () "Return the current/local node." *current-node*) This suggests that there is only one local-node and that it is also called the current-node. My interpretation, then, is that all other nodes will be associated with separate Lisp invocations. In other words, without distributed processing there can be only one node. Is this right? Also, the only place I have seen nodes used is in test/process.lisp, which only tests whether a created process is associated with current-node. Are there any other uses for nodes so far? Eric From dirk at dirkgerrits.com Sat Aug 6 22:12:52 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Sat, 06 Aug 2005 15:12:52 -0700 Subject: [erlisp-devel] local nodes, how many? In-Reply-To: <51e1bc3005080614292b4b276f@mail.gmail.com> References: <51e1bc3005080614292b4b276f@mail.gmail.com> Message-ID: <42F535E4.6070202@dirkgerrits.com> Eric Lavigne wrote: > These lines are in erlisp/src/node.lisp: > > (defvar *current-node* (make-instance 'local-node)) > > (defun current-node () > "Return the current/local node." > *current-node*) > > This suggests that there is only one local-node and that it is also > called the current-node. Well yeah, current-node is perhaps not such a great name. But I named it like that because it's basically also the node of the current- process. I'm not really attached to the name though, suggestions are welcome. > My interpretation, then, is that all other nodes will be associated > with separate Lisp invocations. In other words, without distributed > processing there can be only one node. Is this right? Well yes, distributed programming is the whole thing nodes are for. If you just do parallel programming you only use processes on the current/local node. > Also, the only place I have seen nodes used is in test/process.lisp, > which only tests whether a created process is associated with > current-node. Are there any other uses for nodes so far? Well, no, because distribution isn't implemented yet. Feel free to change that. ;) I'll also try to work on that some time, but I've got to find a way to allocate more spare time... - Dirk From lists at alphageeksinc.com Fri Aug 12 10:32:47 2005 From: lists at alphageeksinc.com (Heow Eide-Goodman) Date: Fri, 12 Aug 2005 10:32:47 -0000 Subject: [erlisp-devel] FYI Message-ID: <1122477267.670.12.camel@sushi> PlanetLisp has this snippit regarding high-performance CL network servers: Joel Reymont is having problems getting details on how best to do a high perfomance network server in lisp. The main problem seems to be that the various Common Lisp network servers are threaded and each thread takes up 2-4MB of heap. This limits the amount of threads that can be spawned. With Erlang I can just launch a process to handle my incoming request, one process per request, without worries. I'm using Allegro CL, a top-notch Lisp implementation and I have to worry that each thread is gonna eat up 2-4Mb of memory. There seems to be no guidance or established pattern on how to write a high-performance network server in Lisp. From patrickdlogan at stardecisions.com Fri Aug 12 16:07:41 2005 From: patrickdlogan at stardecisions.com (Patrick D. Logan) Date: Fri, 12 Aug 2005 12:07:41 -0400 Subject: [erlisp-devel] FYI Message-ID: <1123862860.26008@stardecisions.com> > various Common Lisp network servers are threaded and each > thread takes up 2-4MB of heap. This limits the amount of threads that > can be spawned. > With Erlang I can just launch a process to handle my incoming > request, one process per request, without worries. For comparison, Gambit Scheme takes about 1k per thread. Thread creation appears to stay under 3 microseconds as long as the heap remains abundant. These numbers are essentially the same as Erlang's. http://www.erlang.org/ml-archive/erlang-questions/200212/msg00058.html Obviously room for improvement in CL if any of the providers take an interest in highly concurrent systems. -Patrick From lavigne.eric at gmail.com Mon Aug 22 17:09:37 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Mon, 22 Aug 2005 17:09:37 +0000 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <653bea16050822091551360287@mail.gmail.com> References: <653bea16050822091551360287@mail.gmail.com> Message-ID: <51e1bc3005082210092dcbb08@mail.gmail.com> > 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 From fahree at gmail.com Mon Aug 22 16:15:18 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 22 Aug 2005 12:15:18 -0400 Subject: [erlisp-devel] Erlisp progress? Message-ID: <653bea16050822091551360287@mail.gmail.com> 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!"... From dirk at dirkgerrits.com Mon Aug 22 18:23:49 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 22 Aug 2005 11:23:49 -0700 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <51e1bc3005082210092dcbb08@mail.gmail.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> Message-ID: <430A1835.3060800@dirkgerrits.com> 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 From lavigne.eric at gmail.com Mon Aug 22 19:53:54 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Mon, 22 Aug 2005 19:53:54 +0000 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <430A1835.3060800@dirkgerrits.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> Message-ID: <51e1bc3005082212534ece0710@mail.gmail.com> > > 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 From dirk at dirkgerrits.com Mon Aug 22 20:34:20 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 22 Aug 2005 13:34:20 -0700 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <51e1bc3005082212534ece0710@mail.gmail.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> Message-ID: <430A36CC.3050700@dirkgerrits.com> 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 From lavigne.eric at gmail.com Mon Aug 22 22:30:39 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Mon, 22 Aug 2005 22:30:39 +0000 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <430A36CC.3050700@dirkgerrits.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> <430A36CC.3050700@dirkgerrits.com> Message-ID: <51e1bc3005082215301cad97c4@mail.gmail.com> > > 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 From chris.double at double.co.nz Mon Aug 22 23:00:25 2005 From: chris.double at double.co.nz (Chris Double) Date: Tue, 23 Aug 2005 11:00:25 +1200 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <51e1bc3005082215301cad97c4@mail.gmail.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> <430A36CC.3050700@dirkgerrits.com> <51e1bc3005082215301cad97c4@mail.gmail.com> Message-ID: <1124751625.27243.241240375@webmail.messagingengine.com> > 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. -- http://radio.weblogs.com/0102385 -- Chris Double chris.double at double.co.nz From patrickdlogan at stardecisions.com Mon Aug 22 23:31:06 2005 From: patrickdlogan at stardecisions.com (Patrick D. Logan) Date: Mon, 22 Aug 2005 19:31:06 -0400 Subject: [erlisp-devel] Process linking Message-ID: <1124753464.24853@stardecisions.com> >> 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. Yes, they have to be explicitly linked. > Should it also be possible to link processes which do not have a > parent-child relationship? Yes, links are not just parent-child. See... http://erlang.org/course/error_handling.html#layer Also links in Erlang are two-way... > Are links two-way... > 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? There could be multiple. (A perhaps-obvious-to-most note: these are not OS kill signals. I'm not sure how familiar people are here with Erlang's lightweight processes.) >> 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. My understanding of Erlang's internals is a bit fuzzy so some of this is may be incorrect: Each node has a kind of process monitor. Each process in the node has a mailbox. Communication between nodes essentially occurs at the node level (which cuts down the number of real connections a good bit.) When a connection is lost between nodes (and perhaps cannot be re-established reasonably), any linked processes will be killed by the process monitor or the process monitor will put a message in the process' mailbox if that is the nature of the link. Likewise if a process exits but the node and connection are ok, then the process monitor would send word of this to the linked processes. Then the behavior above kicks in just as in the lost connection case. -Patrick From lavigne.eric at gmail.com Tue Aug 23 01:56:05 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Tue, 23 Aug 2005 01:56:05 +0000 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <1124751625.27243.241240375@webmail.messagingengine.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> <430A36CC.3050700@dirkgerrits.com> <51e1bc3005082215301cad97c4@mail.gmail.com> <1124751625.27243.241240375@webmail.messagingengine.com> Message-ID: <51e1bc30050822185637a2e8ea@mail.gmail.com> > "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 From dirk at dirkgerrits.com Tue Aug 23 02:10:40 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 22 Aug 2005 19:10:40 -0700 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <51e1bc30050822185637a2e8ea@mail.gmail.com> References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> <430A36CC.3050700@dirkgerrits.com> <51e1bc3005082215301cad97c4@mail.gmail.com> <1124751625.27243.241240375@webmail.messagingengine.com> <51e1bc30050822185637a2e8ea@mail.gmail.com> Message-ID: <430A85A0.70100@dirkgerrits.com> 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 From lispnik at gmail.com Tue Aug 23 03:51:26 2005 From: lispnik at gmail.com (Ivan Boldyrev) Date: Tue, 23 Aug 2005 10:51:26 +0700 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: <51e1bc3005082212534ece0710@mail.gmail.com> (Eric Lavigne's message of "Mon, 22 Aug 2005 19:53:54 +0000") References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> Message-ID: 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? -- Ivan Boldyrev | recursion, n: | See recursion From lavigne.eric at gmail.com Tue Aug 23 12:29:51 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Tue, 23 Aug 2005 12:29:51 +0000 Subject: [erlisp-devel] Re: Erlisp progress? In-Reply-To: References: <653bea16050822091551360287@mail.gmail.com> <51e1bc3005082210092dcbb08@mail.gmail.com> <430A1835.3060800@dirkgerrits.com> <51e1bc3005082212534ece0710@mail.gmail.com> Message-ID: <51e1bc30050823052954c2503b@mail.gmail.com> > > 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 From lavigne.eric at gmail.com Thu Aug 25 18:43:28 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Thu, 25 Aug 2005 14:43:28 -0400 Subject: [erlisp-devel] name(s) for link function Message-ID: <51e1bc3005082511437976fbdc@mail.gmail.com> If links will be uni-directional, then there is a need to distinguish the direction of a link. I am looking for discussion and suggestions regarding how to do this. I propose that (link pid) be used to indicate that *current-process* be notified when process pid terminates. I imagine that this is the more common case. A process needs to know about an event, so it requests notification. The other direction (reverse-link pid) would mean that *current-process* should send notification to process pid when *current-process* terminates. Anyone think that these two names should be reversed? Perhaps reverse-link is more useful and should get the simpler name? Any thoughts about a better name than reverse-link? I will be writing these functions over the next couple days, so it would be convenient to know in advance what names we will be using for them. This may seem like a trivial matter, but such things tend to be difficult to change (backwards compatibility issues). Let's find something that we will be comfortable with later. Eric From chris.double at double.co.nz Thu Aug 25 22:25:55 2005 From: chris.double at double.co.nz (Chris Double) Date: Fri, 26 Aug 2005 10:25:55 +1200 Subject: [erlisp-devel] name(s) for link function In-Reply-To: <51e1bc3005082511437976fbdc@mail.gmail.com> References: <51e1bc3005082511437976fbdc@mail.gmail.com> Message-ID: <1125008755.22675.241503331@webmail.messagingengine.com> > The other direction (reverse-link pid) would mean that > *current-process* should send notification to process pid when > *current-process* terminates. Is reverse-link needed? I would think that 'link' is all I would use and just use 'link' in both processes. Chris. From dirk at dirkgerrits.com Thu Aug 25 18:05:11 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 25 Aug 2005 20:05:11 +0200 Subject: [erlisp-devel] Description of pushed patches. Message-ID: <430e0857.PIUsnE05nyEfHQjr%dirk@dirkgerrits.com> Expanded timeout clause syntax to support time-units. condition-terminates-process Eric Lavigne **20050824163858 handler-case added to spawn. Unhandled conditions signalled by a process will kill that process, rather than interrupting the entire lisp image. This provides a convenient way to kill processes, by signalling a condition. In later patches, the handler-case for may include code for sending termination messages to linked processes. From dirk at dirkgerrits.com Thu Aug 25 18:16:37 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Thu, 25 Aug 2005 20:16:37 +0200 Subject: [erlisp-devel] name(s) for link function In-Reply-To: <51e1bc3005082511437976fbdc@mail.gmail.com> References: <51e1bc3005082511437976fbdc@mail.gmail.com> Message-ID: <430E0B05.3080403@dirkgerrits.com> ric Lavigne wrote: > I propose that (link pid) be used to indicate that *current-process* > be notified when process pid terminates. I imagine that this is the > more common case. A process needs to know about an event, so it > requests notification. Seems perfectly reasonable to me. > The other direction (reverse-link pid) would mean that > *current-process* should send notification to process pid when > *current-process* terminates. In this case I would make the API (link :to pid) (link :from pid) (link :to-from pid) But I agree with Chris that there is probably no need to be able to create an incoming link. The process that wants to be informed of the other's death should call LINK. > Anyone think that these two names should be reversed? ... This may > seem like a trivial matter, but such things tend to be difficult to > change (backwards compatibility issues). Let's find something that we > will be comfortable with later. Although I like your thinking, I want to reserve the right to change the Erlisp API (even drastically) without regard to backwards compatibility, at /least/ until a 0.1 release. ;) - Dirk From lavigne.eric at gmail.com Fri Aug 26 11:36:54 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Fri, 26 Aug 2005 11:36:54 +0000 Subject: [erlisp-devel] name(s) for link function In-Reply-To: <430E0B05.3080403@dirkgerrits.com> References: <51e1bc3005082511437976fbdc@mail.gmail.com> <430E0B05.3080403@dirkgerrits.com> Message-ID: <51e1bc30050826043644879265@mail.gmail.com> > > I propose that (link pid) be used to indicate that *current-process* > > be notified when process pid terminates. I imagine that this is the > > more common case. A process needs to know about an event, so it > > requests notification. > > > The other direction (reverse-link pid) would mean that > > *current-process* should send notification to process pid when > > *current-process* terminates. > > In this case I would make the API > (link :to pid) > (link :from pid) > (link :to-from pid) I like the idea, but it is not clear to me which direction :from and :to refer to. Which one matches my "link" and which matches "reverse-link"? Which one says "please notify me when you terminate"? Which one says "I will notify you when I terminate"? > Although I like your thinking, I want to reserve the right to change the > Erlisp API (even drastically) without regard to backwards compatibility, > at /least/ until a 0.1 release. ;) Consider the right reserved :-) So early in development, flexibility is more important than backwards compatibility. Eric From dirk at dirkgerrits.com Fri Aug 26 14:53:01 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Fri, 26 Aug 2005 07:53:01 -0700 Subject: [erlisp-devel] name(s) for link function In-Reply-To: <51e1bc30050826043644879265@mail.gmail.com> References: <51e1bc3005082511437976fbdc@mail.gmail.com> <430E0B05.3080403@dirkgerrits.com> <51e1bc30050826043644879265@mail.gmail.com> Message-ID: <430F2CCD.4020701@dirkgerrits.com> Eric Lavigne wrote: >>In this case I would make the API >>(link :to pid) >>(link :from pid) >>(link :to-from pid) > > > I like the idea, but it is not clear to me which direction :from and > :to refer to. Which one matches my "link" and which matches > "reverse-link"? Which one says "please notify me when you terminate"? > Which one says "I will notify you when I terminate"? Yes that's a problem with both proposed API's. ;) Anyway, as was said earlier, it'd probably be better if the process that wants to be notified always initiates the link, so there would only be a (LINK pid) and there could be little confusion. - Dirk From lavigne.eric at gmail.com Mon Aug 29 16:03:07 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Mon, 29 Aug 2005 12:03:07 -0400 Subject: [erlisp-devel] receiving, pattern-matching Message-ID: <51e1bc300508290903ed9416@mail.gmail.com> How does receive work? I see that one of the arguments is a pattern for indicating what sort of message I am interested in, but I don't understand how to write/interpret such a pattern. Also, will I receive only the first message that matches this pattern? What happens if no messages match the pattern? Returns nil immediately? Block until such a message arrives? Specifically, I would like to send a list as a message and recognize the message type based on the first element. Example (recognize that this starts with 'system): (list 'system 'link-request 'notify) I would like to receive the first message from the mailbox in *current-process* whose first element is 'system, returning immediately in the case where no such message is found. How could I set up a pattern-matcher for this? Can I use receive? Or will I need to use receive-with-timeout and a short time limit? Better still, is there a way to set up a default handler that would perform predefined action whenever a message matching its pattern shows up? If so, I would like to use this. If not, I think it would be worth adding later. I can imagine writing an entire program made up entirely of default handlers for various message patterns. I think that I'm very close to finishing process-linking, but my confusion over the messaging system is holding me back. Eric From dirk at dirkgerrits.com Mon Aug 29 17:35:29 2005 From: dirk at dirkgerrits.com (Dirk Gerrits) Date: Mon, 29 Aug 2005 10:35:29 -0700 Subject: [erlisp-devel] receiving, pattern-matching In-Reply-To: <51e1bc300508290903ed9416@mail.gmail.com> References: <51e1bc300508290903ed9416@mail.gmail.com> Message-ID: <43134761.1010204@dirkgerrits.com> Eric Lavigne wrote: > How does receive work? I see that one of the arguments is a pattern > for indicating what sort of message I am interested in, but I don't > understand how to write/interpret such a pattern. Depends on the matcher used. Erlisp currently only has COND and CASE based matcher, which are very lame. See test/matcher.lisp and test/messaging.lisp for examples. It should be easy to write support for fare-matcher (or whatever matcher you want) though. > Also, will I receive only the first message that matches this pattern? Yep. To process all matching messages you do RECEIVE with a 0 timeout in a loop, and make the timeout clause end the loop. > What happens if no messages match the pattern? Returns nil > immediately? Block until such a message arrives? Block until such a message arrives, or the timeout is reached (if one is specified). > Specifically, I would like to send a list as a message and recognize > the message type based on the first element. > Example (recognize that this starts with 'system): > (list 'system 'link-request 'notify) > I would like to receive the first message from the mailbox in > *current-process* whose first element is 'system, returning > immediately in the case where no such message is found. How could I > set up a pattern-matcher for this? Can I use receive? Or will I need > to use receive-with-timeout and a short time limit? This should do the trick, though I can't test it before I get back to my laptop in a couple of hours: (receive-with-matcher (cond-matcher m) ((and (consp m) (eq (car m) 'system)) ...) ((:timeout 0) nil)) > Better still, is there a way to set up a default handler that would > perform predefined action whenever a message matching its pattern > shows up? There is not. Could you define "whenever a message matching its pattern shows up" exactly? Would it be as if every RECEIVE has additional invisible clauses above the explicitly written ones? > If so, I would like to use this. If not, I think it would be worth > adding later. I can imagine writing an entire program made up > entirely of default handlers for various message patterns. Doesn't seem very Erlangy to me, but that's not the purpose of Erlisp anyway. ;) If you can demonstrate to me why this would be an advantage and how we could implement it, then I'm all for it, but at the moment I can see neither. - Dirk From fahree at gmail.com Mon Aug 29 17:56:28 2005 From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=) Date: Mon, 29 Aug 2005 13:56:28 -0400 Subject: [erlisp-devel] receiving, pattern-matching In-Reply-To: <51e1bc300508290903ed9416@mail.gmail.com> References: <51e1bc300508290903ed9416@mail.gmail.com> Message-ID: <653bea16050829105630e9a95@mail.gmail.com> Dear Eric, On 29/08/05, Eric Lavigne wrote: > How does receive work? I see that one of the arguments is a pattern > for indicating what sort of message I am interested in, but I don't > understand how to write/interpret such a pattern. Also, will I receive > only the first message that matches this pattern? What happens if no > messages match the pattern? Returns nil immediately? Block until such > a message arrives? Erlisp should neatly decouple two things. (1) receiving, (2) matching. Receiving is blocking, with an optional timeout. With a timeout of 0, it's non-blocking. What you receive is a list. You can then match this list agains patterns -- matching is the natural way of expressing things in Erlang, but not so in Lisp. In Lisp, you *can* use pattern matching. I've written a pattern matcher (fare-matcher) with Erlang and ML in mind. Other matchers are available (there's one in UCW, IIRC, and then there's Screamer). What should happen when you receive something that doesn't match any pattern? I don't remember what happens in Erlang: either the message is dropped or it raises an error, I suppose (gotta read the documentation). In Lisp, it could be configurable. See match vs ematch just like we have case vs ecase. > Better still, is there a way to set up a default handler that would > perform predefined action whenever a message matching its pattern > shows up? The Erlang way of doing things would be to spawn another process for the things you want to be done in background of your main process. Remember: processes are cheap, in the Erlang model. Hopefully, so will they eventually be with Erlisp (especially processes sleeping on a receive). [ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] information we gather and create overflows our means of managing it our ppl r only happenstancely synergistic From bryan-lisp at lunch.org Tue Aug 30 03:27:19 2005 From: bryan-lisp at lunch.org (bryan o'connor) Date: Mon, 29 Aug 2005 20:27:19 -0700 Subject: [erlisp-devel] openmcl patches Message-ID: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> i've filled in the missing pieces in compatibility.lisp to support openmcl. all tests pass reliably except the test receive-with-timeout occassionally runs a few milliseconds too long. my darcs repo is here: http://monday-monkey.com/repos/erlisp/ ...bryan From lavigne.eric at gmail.com Tue Aug 30 05:09:33 2005 From: lavigne.eric at gmail.com (Eric Lavigne) Date: Tue, 30 Aug 2005 05:09:33 +0000 Subject: [erlisp-devel] openmcl patches In-Reply-To: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> References: <9BB720B4-230F-46F3-8DC4-56D7E7DDF788@lunch.org> Message-ID: <51e1bc3005082922095eabd8aa@mail.gmail.com> > i've filled in the missing pieces in compatibility.lisp to > support openmcl. all tests pass reliably except the test > receive-with-timeout occassionally runs a few milliseconds > too long. > > my darcs repo is here: > http://monday-monkey.com/repos/erlisp/ > > > ...bryan > I had exactly the same problem the first time I tried to add CMUCL support. The line that helped CMUCL was (mp:process-yield), which made an order-of-magnitude difference in the amount of wasted time in the polling loop (though it would be better to not have a polling loop at all). Does OpenMCL have something similar? It sounds like you are most of the way there. The hard part is making it work at all, and you've done that. Optimizing to boost the speed is comparatively easy. If you can't find a way to improve the speed, it might be okay to submit your changes as they stand. Add a comment line in the event-wait function indicating that some optimization is needed for the OpenMCL version, make a similar note in the patch description, and submit the 90% solution that might be useful as-is and that we can work on improving later. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From gefla at pond.sub.org Tue Aug 30 08:34:03 2005 From: gefla at pond.sub.org (Gerd Flaig) Date: Tue, 30 Aug 2005 10:34:03 +0200 Subject: [erlisp-devel] Re: receiving, pattern-matching References: <51e1bc300508290903ed9416@mail.gmail.com> <653bea16050829105630e9a95@mail.gmail.com> Message-ID: <874q97rfgk.fsf@kilo.pond.sub.org> Far? writes: > What should happen when you receive something that doesn't match any > pattern? I don't remember what happens in Erlang: either the message > is dropped or it raises an error, I suppose (gotta read the > documentation). In Lisp, it could be configurable. See match vs ematch > just like we have case vs ecase. unmatched messages are buffered. I've attached a small test module demonstrating this. Goodbyte, Gerd. -module(f). -export([r/0]). l() -> receive {a,A} -> io:format('a: ~p~n', [A]) end, receive {b,B} -> io:format('b: ~p~n', [B]) end, receive R -> io:format('r: ~p~n', [R]) end, l(). r() -> Pid = spawn(fun l/0), Pid ! {b, bla}, Pid ! foo, Pid ! {a, blubb}. Eshell V5.4.6 (abort with ^G) 1> c("/tmp/f", [{outdir, "/tmp/"}]). {ok,f} 2> f:r(). a: blubb {a,blubb}b: bla r: foo 3> -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal