Home > Archive > Unix Programming > May 2006 > Child process IDs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Andrei Korostelev 2006-05-31, 8:10 am |
| If I fork a new process in Linux, the PID of a new born one is bigger
than the parent's PID.
Is this fact (child PID > parent PID) specified somewhere or it is
implementation-defined?
I am interested in Linux at least.
| |
| Rainer Temme 2006-05-31, 8:10 am |
| Andrei Korostelev wrote:
> If I fork a new process in Linux, the PID of a new born one is bigger
> than the parent's PID.
No, in principle there is no relationship between the two PIDs ...
> Is this fact (child PID > parent PID) specified somewhere or it is
> implementation-defined?
Most *nix systems use a short int to represent PIDs ... some limit the
PID to be between 1 and 32767. The strategy to get a new PID is
round-robin...
So, if a new process forks very soon after creation, chances are not too
bad, the the very next number is used as PID for the child. (given this
PID is available). But if there were other processes running, that were
forking children at the same time, you cannot predict what number your
new child will get.
When the biggest number is used (e.g. 32767) the next porcess will get
any available PID starting with 1. (Since 1 is usually init and some
others with very low numbers are running permanently as well, the PID
will effectively a bit higher.
So the assumption "ParentPID < ChildPID" is wrong.
Rainer
| |
| Lew Pitcher 2006-05-31, 8:10 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrei Korostelev wrote:
> If I fork a new process in Linux, the PID of a new born one is bigger
> than the parent's PID.
> Is this fact (child PID > parent PID) specified somewhere or it is
> implementation-defined?
No, nor is it guaranteed to be true.
PID values are recycled, so that the PID of a dead process may be reused
later as the PID of a newly spawned process. There is also a wraparound
on PID values.
Together these two factoids mean that a parent process /can/ fork off a
child process that has a PID with a lower numerical value than the
parent. In fact, it /has/ to work that way; PID values are a limited
resource expressed in a limited format - there will /always/ be a chance
of a wraparound.
> I am interested in Linux at least.
>
- --
Lew Pitcher, IT Specialist, Corporate Technology Solutions,
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEfYamagVFX4UWr64RAjUbAJ0XmrHTH5E6
42gCrEoPfcwJU0cVNgCeMtYQ
eZsUc+y4t+a73epDXVKLewE=
=248j
-----END PGP SIGNATURE-----
| |
| Roger Leigh 2006-05-31, 8:10 am |
| | |
| Rainer Temme 2006-05-31, 8:10 am |
| Roger Leigh wrote:
> It's worth noting here that some systems use PID randomisation to make
> the child PID unpredictable for security reasons.
Well, on such a system the only thing that can be reliably predicted is,
that the new PID cannot be the PID of a currently running process.
Rainer
| |
| Andrei Korostelev 2006-05-31, 7:09 pm |
| > Most *nix systems use a short int to represent PIDs ... some limit the
> PID to be between 1 and 32767. The strategy to get a new PID is
> round-robin...
>
> So, if a new process forks very soon after creation, chances are not too
> bad, the the very next number is used as PID for the child. (given this
> PID is available). But if there were other processes running, that were
> forking children at the same time, you cannot predict what number your
> new child will get.
>
> When the biggest number is used (e.g. 32767) the next porcess will get
> any available PID starting with 1. (Since 1 is usually init and some
> others with very low numbers are running permanently as well, the PID
> will effectively a bit higher.
>
> So the assumption "ParentPID < ChildPID" is wrong.
>
> Rainer
Indeed I thought it should be similar to this, a sort of sparse
cirlular buffer.
| |
| Brian Raiter 2006-05-31, 7:09 pm |
| > Well, on such a system
.... or any other Unix system ...
> the only thing that can be reliably predicted is, that the new PID
> cannot be the PID of a currently running process.
b
| |
| Logan Shaw 2006-05-31, 10:02 pm |
| Andrei Korostelev wrote:
> If I fork a new process in Linux, the PID of a new born one is bigger
> than the parent's PID.
It's trivial to show this is not true. If it were, and if a parent
fork()ed two new processes, they'd both have the same pid at the
same time, and that is guaranteed not to happen.
- Logan
| |
| Gordon Burditt 2006-05-31, 10:02 pm |
| >> If I fork a new process in Linux, the PID of a new born one is bigger
>
>It's trivial to show this is not true. If it were, and if a parent
>fork()ed two new processes, they'd both have the same pid at the
>same time, and that is guaranteed not to happen.
No, the quote didn't say the "PID of a new born one is *one* bigger
than the parent's PID.
However, it also means that a process with the maximum PID can't
fork. On some (early) UNIX systems, the maximum PID is something
like 30000 (no, I don't mean 32767, although there may be systems
like that also) so re-using PIDs within the same couple of hours
isn't all that uncommon.
Gordon L. Burditt
| |
| Keith Thompson 2006-05-31, 10:02 pm |
| Lew Pitcher <Lew.Pitcher@tdsecurities.com> writes:
> Andrei Korostelev wrote:
>
> No, nor is it guaranteed to be true.
>
> PID values are recycled, so that the PID of a dead process may be reused
> later as the PID of a newly spawned process. There is also a wraparound
> on PID values.
A while ago, I did some experiments to see how quickly I could make
PID values wrap around. (I wanted to know whether I could, under some
circumstances, assume that a process with a given PID was the same as
a previously known process with the same PID.) I managed to get the
system to re-use a previous PID in about 30 seconds. This isn't
likely to happen in real life, but it was enough to convince me that I
couldn't count on the PID to uniquely identify a process over any
useful span of time.
Incidentally, most Unix-like systems seem to use PIDs in the range
0..32767 or so, but AIX uses PIDs over 2,000,000.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
|
|
|
|
|