- erlisp-devel@lists.common-lisp.net - mailman3.common-lisp.net

[erlisp-devel] receiving, pattern-matching
by Eric Lavigne 01 Sep '05

01 Sep '05

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

6 10

[erlisp-devel] openmcl patches
by bryan o'connor 01 Sep '05

01 Sep '05

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

3 5

[erlisp-devel] Description of pushed patches.
by Dirk Gerrits 01 Sep '05

01 Sep '05

openmcl-threads bryan d. o'connor <bryan(a)lunch.org>**20050830025955 Modified threading procedures in compatibility.lisp to support OpenMCL.

1 0

[erlisp-devel] name(s) for link function
by Eric Lavigne 26 Aug '05

26 Aug '05

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

3 4

[erlisp-devel] Description of pushed patches.
by Dirk Gerrits 25 Aug '05

25 Aug '05

Expanded timeout clause syntax to support time-units. condition-terminates-process Eric Lavigne <lavigne.eric(a)gmail.com>**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.

1 0

[erlisp-devel] Erlisp progress?
by Faré 23 Aug '05

23 Aug '05

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

5 10

[erlisp-devel] Process linking
by Patrick D. Logan 22 Aug '05

22 Aug '05

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

1 0

Re: [erlisp-devel] FYI
by Patrick D. Logan 12 Aug '05

12 Aug '05

> 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

1 0

[erlisp-devel] FYI
by Heow Eide-Goodman 12 Aug '05

12 Aug '05

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.

1 0

[erlisp-devel] local nodes, how many?
by Eric Lavigne 06 Aug '05

06 Aug '05

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

2 1