Messages in this thread | | | Date | Thu, 13 Jan 2000 13:46:58 +0000 (GMT) | From | Matthew Kirkwood <> | Subject | Re: RFC/PATCH: Random pid generation |
| |
On Thu, 13 Jan 2000, Chris Evans wrote:
> > > This is also a really bad idea, because with easily guessable pids you > > > are opening yourself to /tmp races. This is actually a argument for > > > random pids (or fixing the programs). > > > > Random pids just slow the process down. Its an argument for writing > > decent code. > > Random pids in a 32 bit space would take an average of ~1 random > number generation to calculate per fork. That can't be too slow can > it? It would perhaps be a more stable performance statistic than our > current scheme because the current scheme can hit a block of in-use > pids and thus the time to work out a suitable pid had a greater > variance.
But if we had 32-pid pids, the box would have to be up for a very long time before it wrapped the pid counter, hence O(1) work with less overhead than the random option.
A random pid generator can hit inuse pids forever, so, unless you are expensively careful, pid generation can be non-terminating.
Personally, I'd like to see them as an option anyway.
Matthew.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |