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
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
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
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
-
Chris Double -
Dirk Gerrits -
Eric Lavigne