Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: random PID generation | Date | 22 Feb 2001 13:42:56 -0800 |
| |
Followup to: <20010222232423.A18448@home.ds9a.nl> By author: bert hubert <ahu@ds9a.nl> In newsgroup: linux.dev.kernel > > Well - I'm not sure that this is a good idea. When PIDs increase > monotonically, chances are very small that the race condition implicit in > sending any signal to a process results in killing the wrong process (ie, a > new process, but with the same PID) - you'd need to zoom through 32000 PIDs > in a very short time to make this happen. > > With truly random PIDs, there is a much larger chance of a new process > sitting on a recently used PID. > > What would work is to have cryptographically randomly generated PIDs which > would then guarantee not to return a previously returned number within 32000 > tries, and also not be predictable - there must be algoritms out there which > do this. >
It depends on the size of your number space. If you have a 31-bit pid_t (since it apparently must be sign-safe) then you can take random 16-bit numbers from the /dev/urandom code and add to the last used value instead of simple increment.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |