lkml.org 
[lkml]   [2000]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.084 / U:0.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site