Worried About PID Reuse

Questions & Help Questions
1

Hello, I’m new to Elixir, and I keep thinking about a hypothetical scenario that could be problematic due to the way PIDs are generated. Let’s say that process A obtains the PID of process B and is going to send a message to process B. In the meantime, however, process B dies and process C starts with the same PID as process B. If process A sends the message to the PID that is now associated with process C, then process C will crash or cause other problems. Because of this, is there any way to prevent process C from receiving a message intended for process B?

I think that this is very hypothetical since it’s unlikely for a newly created process to have the same PID as a process that just died. However, as far as I know, the BEAM will eventually reuse PID numbers, and if many processes are running at the same time, then it seems possible that a PID belonging to a process that just died will eventually be used for a new process. Because of this, is there any way to prevent the scenario described before?

Thank you.

2

I think your worry makes sense, but the probability of that happening, especially consistently is almost zero.

I just spotted someone has explained that before more in detail (https://stackoverflow.com/a/46140414/22746062).

PS. Elixir is based on Erlang so the answer on Stackoverflow applies to Elixir.

3

It can’t happen. The numbers themselves don’t really mean much and the pid is “just” a reference to an internal data structure.

Actually the firs number has some meaning, if it is 0 then it is a pid referring to a process on this node, otherwise it refers to a process on another node.

A bit of ancient history. Back in the really old days the other numbers did mean something: the 2nd number was the index into the process table of that process and the 3rd was the number of times this index had been used. No risk of reuse then either.

4

@rvirding That’s a relief. Thank you for responding!

@arcyfelix Thank you for the link. It’s very informative.