I can't find any pattern when I look at the numbering of PIDs in process table (ps -a), as the PIDs are not subsequent numbers and sometimes there are large "gaps" between those numbers. Is it because there may be some processes that run for a short time and they reserve some PIDs? Is there some range, after which the numbering of processes resets?
I'm using Mac OS X but I guess that the answer should apply to UNIX in general.
Yes on both counts.
Many processes are short lived. They get a PID, run, finish, and the PID disappears from the process table.
Processes sometimes only live for a fraction of a second!
Often when programs start they run numerous commands as part of checking the system and initializing their environment.
The maximum PID number depends on the system and is sometimes configurable. Basically if you know you are going to have a huge number of processes, then you may need to increase the number, but on new operating systems I believe the maximum number is typically large enough for most any workload.
PIDs are entries in the process table, and the more you have the more memory the process table takes up.
Have a look at this related question: https://serverfault.com/questions/279178/what-is-the-range-of-a-pid-on-linux-and-solaris
Also note that related to this is the "maximum nr of processes per user" which is a measure to protect against a malicious user intentionally creating many processes to hog the whole process table.
It is also possible to configure some modern kernels to assign random PIDs to new processes for improved security. At least Linux and FreeBSD can do it with a sysctl setting, and OpenBSD does it always. In those cases you can say ever less about the numbering schemas.
Processes in UNIX are very light, cheap and are born by forking(!).
The forking aspect often eludes users, sysadmins and programmers alike, especially those who are coming from so called "spawn" oriented systems like Windows.
Windows cannot fork, or rather, it can only fork threads (technically it can fork, but this API is beyond reach of WINAPI programs).
I.e. on UNIX, fork is much more similar to thread spawning, than to Windows process spawning. It splits initial process into itself and it's child that is running copy of it's parent and both share same data and history up until the point of the fork (then their respective histories start to slowly but steadily diverge).
As was already said in other answers, this all (cheapness, quickness, lightweightness) means PIDs can appear and go away very, very quickly.
Please understand that traditional UNIX way of writing internet servers is to use one fork per one connection model - this essentially means that one new PID is spawned for each connection.
Just think about it in context of very busy image serving http server: each time image is displayed to a remote client, this means new PID is forked image data is read and sent and then PID is consumed, all happening in very quick succession during fraction of a second. Traditional ftp, but also many lightweight http servers are still being written in such a way to this day.
Another initially weird aspect of UNIX is, that defunct ie. dead processes don't release their PIDs! By the time process of given PID has ended, it has no way to affect the PID still being held in any way. Yet this PID remains allocated and occupies/hogs the system process table.
Why is that? Because under that process table PID record program exit code value and various accounting counters of that process are being held!
This is so CPU and memory accounting programs can read information of their children, even after they have ended.
We call such a defunct accounting record a ZOMBIE.
It means that until specific zombie is processed, its PID cannot be reused (ie several zombies waiting to be accounted for can cause "holes" in case of UNIX systems with very naive linear PID assignement scheme) for newly forking processes.
It is responsibility of process's parent process to "reap" the zombie, ie to consume its accounting information and thus return zombie's PID into the pool of "free PIDs" for other forking processes to reuse.
Given all these facts, even if PID generation is naively linear algorithm preffering to reuse first "unoccupied" PID possible, we see that various system actions like parental zombie reaping, will result with PID never being strictly linearly growing.
On all modern systems completely random PID assignment algorithms can be activated, but OpenBSD is an only system where it mandatory enforced by default.
Thus we should always treat PIDs as completely opaque identifiers.
