<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Back to your problem - PID reuse is painful to workaround. I would<br>
suggest something like storing in a process belonging to connection,<br>
which database they are connected to (some kind of validation data).<br>
You will also need to extend "gen_server:call" with the same<br>
validation data, and the connection process will then check, if<br>
validation data is correct.<br></blockquote><div><br></div><div>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 ever.</div><div><br></div><div>The only safe solution I can think of would go like this:</div><div><ol><li>Find out the pid you should use</li><li>Monitor the pid</li><li>Find out the pid you should use again.</li><ul><li>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 new one.</li><li>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 theoretically possible 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 this madness!)</li></ul><li>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!</li><li>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 different processes.</li></ol><div>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.</div></div><div><br></div><div>Cheers,</div><div>Daniel</div></div></div>