Detect pid reuse
Thu Jul 9 22:11:57 CEST 2020
> Back to your problem - PID reuse is painful to workaround. I would
> suggest something like storing in a process belonging to connection,
> which database they are connected to (some kind of validation data).
> You will also need to extend "gen_server:call" with the same
> validation data, and the connection process will then check, if
> validation data is correct.
This solution assumes the new process that is reusing the pid will also be
a connection process that understands this protocol. But there's no
guarantee for that, once you're fighting pid reuse, the new process may be
any process that your system can spawn. It may not even execute a receive
The only safe solution I can think of would go like this:
1. Find out the pid you should use
2. Monitor the pid
3. Find out the pid you should use again.
- If it's different from the old one you already have, you've just
run into pid reuse. Demonitor the old pid and go back to step 2 with the
- If it's the same as the old one, you are most likely having the
monitor on the process you want to use. (It's still
that in step 1 you got a pid of process X, which died and a completely
different process Y reused its pid, so you monitored that in step 2, but
process Y also died and now a new process Z is reusing the pid, and Z is
actually the replacement of the dead process X, so in step 3 you actually
look up Z. But don't worry, you're covered with this algorithm even for
4. Whenever you need to receive a message from the pid, also have a
receive clause for the DOWN message from the monitor. This includes
receives within the gen_* modules, so either be very disciplined and use
your custom reimplementation of gen_server:call/cast/... instead, or build
your own patched OTP, yay!
5. Be sure that all processes in your system can handle unexpected
garbage messages (by at least throwing them away from their mailbox),
because they themselves can become pid reusers and receive messages
intended to different processes. Also make sure that all processes are
capable of telling messages targeted to them from messages intended to
However, I'm afraid this would be an extremely inefficient solution with
the double pid lookups and monitors alone. And steps 4 & 5 seem practically
impossible to implement correctly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions