> I have seen severl posts (over the last couple of years) where
> people complained about either performance or security problems related
> to generating PID numbers for child processes at fork() time. There is
> the assumption that PID numbers increase, skipping over in-use PIDs,
> and then wrap at 32K. I dont think Digital Unix does it this way:
>
> This looks almost random, and it does not seem to break anything.
> I just wanted to let people know that if we wanted to use some other
> scheme for generating PIDs, there is some precident for doing so.
It could be done, but it would surely cost a little
performance.
A very cheap way to do it would be to:
- make a used/unused PID bitmap
- divide that bitmap into HZ pieces
- look into the 'jiffies'th part if there's some free PID
- if not, try the next area
But still, it might put us behind QNX and Lynx in forking
speed :-)
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu