Thu Mar 27 01:51:38 CET 2003
Ulf Wiger wrote:
>I'm not sure if it's possible, or even relevant to solve the
>general case of a server trying to make sure that there are
>no more messages before it finally dies. After all, this is
>fundamentally a race condition.
It's evidently not a huge problem in practice.
I've refined my guideline: in waiting for a reply,
a) if you monitor the process, always accept a DOWN message as a valid
reply (as Vlad S. pointed out);
b) if you link to the process, always accept an EXIT message as a valid
reply (unless you want your process to die too);
c) if you don't monitor or link, always use a finite timeout.
To avoid the timeout in the case of c) (just thinking out loud here, not
suggesting anything) you'd need an atomic recieve_or_exit.
Ulf also wrote:
>However, reg_name ! foo _will_ fail if there is no process
>registered as 'reg_name'.
However, if we wanted to take this approach for avoiding timeouts
(again, just thinking out loud), not only would we need an atomic
recieve_or_unregister_self, we would have a need to register processes
dynamically, so we'd need to either garbage-collect the atom table, or
allow processes to be named with arbitrary (or at least
garbage-collectable) terms. A bit messy, any way you slice it.
I have yet to use monitor; I learned Erlang from "the book" and I've
been slower to adopt things that aren't mentioned in it. I should
definately look into it soon.
More information about the erlang-questions