> Az egyik elméleti probléma a PID-ek túlcsordulása lehet, bár a maximum PID-et már elég jól lehet emelni, és azért annak elég kicsi az esélye, hogy mióta kilépett egy processz, de még azelőtt, hogy ránéznél, a PID-jét elfoglalta egy másik.
A PID-reoccupy-overlap nem probléma - nem lehet probléma - hiszen ezek child processek, a processünk kreálja őket, nem maguktól jönnek létre. Ennek megfelelően, ha egy frissen létrehozott child process visszakapott PID-je már szerepel a táblában, akkor egyértelmű, hogy az csak úgy lehet, ha a korábbi tulajdonos kiszállt és újra kiosztották a PID-jét. Ennek megfelelően az általad említett overlap nem lehetséges.
> A másik meg az, hogy ha sok rövid életű processz van, akkor gyakran kell végig kill 0-zni az egész listát.
Nem muszáj a SIGCHLD-ra várni, erre írtam fentebb, hogy akár periodikusan is lehet nézgeteni ezt a táblát, teljesen ignorálva a SIGCHLD signalokat. Akkor nincs signal-összeolvadás, nincsenek egymásba érő PID check ciklusok.
> Őszintén már nem emlékszem, hogy mennyi volt a legtöbb worker processz, amit láttam, de sok. :)
Hát ez azért elég tág tartomány. :)
> Igazából azt gondolom, hogy tényleg kicsi az esélye annak, hogy ebből is versenyhelyzet legyen, de minél terheltebb rendszerről beszélünk, annál meredekebben emelkedik, mert a hatások egymást erősítik (a szabad PID-ek számának csökkenése, a lassulás, és a kezelendő lista növekedése).
Lehet, de ha tényleg annyi processünk lesz, akkor IMHO előbb fogynak el a fizikai erőforrások a rendszer alól, mintsem, hogy érzékelhetővé váljon a PID lista kezelésének lassúsága.
> De hirtelen én se látok jobb megoldást.
Na, majd mérek egyet valamikor.