<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 11:23 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is however assuming there are only two processes in your system, and everything is well written and pids don't wrap up (which they apparently do?)</blockquote><div><br></div><div>I don't think adding more processes can tickle a bug which is not found by two processes here. If I have N processes racing for this, only one has to go before. Once I know which, I can ignore all the other processes. So the problem can be reduced to a 2-process model I think. <br></div></div><br></div><div class="gmail_extra">Pids internally have a 28 bit structure so wrap-around can occur if you manage to generate 268 million processes, and come around again. It depends a lot on your internal architecture if this will happen or not in a practical setting.<br><br>The scenario is that an old process might have been holding on to an old Pid and tries to reuse it and now a new process exist in its name.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">268 million sounds way too low on a 64 bit architecture however. There you have 60 bits rather than 28, so you would not hit any limit at all were these used. There is some effort in switching over however. If you've hit these limits, I think it is worthwhile to mention that you did. As systems grow ever more complicated, earlier ceilings will eventually be hit and knowing in advance it can happen is nice.<br><br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>