только на время жизни.
сами подумайте, множество значений pid в любом
случае ограниченно.
cvv, почему у вас всегда "Ето" вместо "Это" ?
просто любопытно :)
Как показано в соседнем треде sizeof(pid_t) как минимум в ядре 2.4.28 равно 4 байтам те система гарантирует уникальность pid на каждые 4 миллиарда процессов. Думаю это достаточно для любых приложений :)
> Как показано в соседнем треде sizeof(pid_t) как минимум в
> ядре 2.4.28 равно 4 байтам те система гарантирует уникальность
> pid на каждые 4 миллиарда процессов. Думаю это достаточно
> для любых приложений :)
при чем здесь sizeof(pid_t)? можете его хоть 64-разрядным
сделать.
в 2.4 #define PID_MAX 0x8000
в 2.6 это можно увеличить.
для 2.4
include/linux/threads.h:
#define PID_MAX 0x8000
kernel/fork.c:int get_pid()
ограничения на макс количество процессов связаны
именно с ведением базы данных использованных pid.
для 2.6
kernel/pid.c
максимальный (pid_max_max) pid может быть задан через
/proc/sys/kernel/pid_max
fs/proc/ имеет проблемы c большими значениями pid, поэтому
в 2.10 значение PID_MAX_LIMIT уменьшено для 32 битных cpu.
кроме того, некоторые user-level приложения ломаются при
больших pid_max_max, т.к. хранят pid в signed short.
pid процесса уникален только на время жизни процесса
Процессы создаются с уникальными pid-ами, если нет свободных pid-ов, fork(1) не производится. Это единственное, на что стоит закладываться.
Традиционно это реализуется путем присвоения последовательных номеров, и, если пиды кончатся, ядро будет выбирать последовательные свободные номера с начала.
Однако, вполне можно использовать случайные pid (grsecurity, например), всегда выбирать наименьший свободный и т.д. -- никто не мешает.