Prev: How to extract a C function definition from a C source file
Next: While loop slowness
From: yocohen on 1 Apr 2008 10:03
Hi,

I couldn't google out the answer. Is the process id number always
ascending? i.e. if I start process A and a second later start process
B, can I be sure that process id of B will be bigger than process id
of A?
I believe there is an issue when we run out of numbers (what is the
max number, BTW?), but assuming this may happen rarely, what is the
common behavior?

Thanks,

Yossi
From: Greg Andrews on 1 Apr 2008 10:22
yocohen(a)gmail.com writes:
>Hi,
>
>I couldn't google out the answer. Is the process id number always
>ascending? i.e. if I start process A and a second later start process
>B, can I be sure that process id of B will be bigger than process id
>of A?
>I believe there is an issue when we run out of numbers (what is the
>max number, BTW?), but assuming this may happen rarely, what is the
>common behavior?
>

The answer to your third question is: The kernel gives the new process
the lowest unused process id, and resumes the pattern of assigning
ascending (unused) process ids to new processes.

Therefore the answer to your first question is: No, it isn't certain
that the id for process B will be larger than for process A.

The answer to your second question is: It depends on the particular
operating system implementation. In some the maximum process id can
be adjusted.


-Greg
--
::::::::::::: Greg Andrews ::::: gerg(a)panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright
From: Janis on 1 Apr 2008 10:26
On 1 Apr., 16:03, yoco...(a)gmail.com wrote:
> Hi,
>
> I couldn't google out the answer. Is the process id number always
> ascending?

No, not always. (Think about it; that cannot be true with any
limited range of numbers.)

> i.e. if I start process A and a second later start process
> B, can I be sure that process id of B will be bigger than process id
> of A?

No, there's a wrap around at some point. (I think at least a
15-bit number is used, so that would then be at 32767. Though,
I can imagine systems that have a larger domain.)

> I believe there is an issue when we run out of numbers (what is the
> max number, BTW?), but assuming this may happen rarely, what is the
> common behavior?

The number selection restarts from the low numbers incrementally
while using only the free (i.e. currently non-assigned) numbers.

You only "run out" of numbers if the number of running processes
exceeds a system limit; in that case, even if still free process
numbers available, you won't be able to start another process.

Janis
From: yocohen on 1 Apr 2008 10:43
On Apr 1, 5:22 pm, g...(a)panix.com (Greg Andrews) wrote:
> yoco...(a)gmail.com writes:
> >Hi,
>
> >I couldn't google out the answer. Is the process id number always
> >ascending? i.e. if I start process A and a second later start process
> >B, can I be sure that process id of B will be bigger than process id
> >of A?
> >I believe there is an issue when we run out of numbers (what is the
> >max number, BTW?), but assuming this may happen rarely, what is the
> >common behavior?
>
> The answer to your third question is:  The kernel gives the new process
> the lowest unused process id, and resumes the pattern of assigning
> ascending (unused) process ids to new processes.
>
> Therefore the answer to your first question is:  No, it isn't certain
> that the id for process B will be larger than for process A.
>
> The answer to your second question is:  It depends on the particular
> operating system implementation.  In some the maximum process id can
> be adjusted.
>
>   -Greg
> --
> :::::::::::::  Greg Andrews  :::::  g...(a)panix.com  :::::::::::::
>      I have a map of the United States that's actual size.
>                                 -- Steven Wright

Hi,

Thanks for prompt response. I find some ambiguity in the answer as I
understand it, so I will rephrase the question :)
Assuming there is no number limit, will process id be assigned in
ascending pattern?

Thanks,

Yossi
From: Daniel Rock on 1 Apr 2008 11:04
yocohen(a)gmail.com wrote:
> Hi,
>
> I couldn't google out the answer. Is the process id number always
> ascending? i.e. if I start process A and a second later start process
> B, can I be sure that process id of B will be bigger than process id
> of A?
> I believe there is an issue when we run out of numbers (what is the
> max number, BTW?), but assuming this may happen rarely, what is the
> common behavior?

No, I don't know the algorithm AIX chooses the next PID but you cannot
rely on increasing PIDs:

$ sh -c 'echo $$'
2244706
$ sh -c 'echo $$'
2244708
$ sh -c 'echo $$'
2187416
$ sh -c 'echo $$'
2244712
$ sh -c 'echo $$'
2203804

You see? There seems to be a pattern, but nothing you can depend on.

pid_t is on most system a 32 bit signed integer. So in theory PIDs could
go up to MAX_INT. In practise most OS wrap PIDs around MAX_SHORT.

Solaris wraps at 30000, this can be adjusted by setting pidmax in
/etc/system. FreeBSD used to wraps at 32767, now wraps at 99999 (to avoid
formatting problems where only 5 chars are reserved for printing PIDs, like
in printf("%5d", pid))

So you should put no assumption on PIDs in your scripts.

--
Daniel
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: How to extract a C function definition from a C source file
Next: While loop slowness