[quotemstr]

It works out all right on Windows, which uses exactly the approach I advocate. And you can already DoS the system in myriad ways. If you're still worried: we have ulimits for other resources. We can have a ulimit for this one too.

[colin_mccabe]

I agree that there are already many ways to DoS the system-- for example, the age-old fork bomb. But that is not a good reason to add more flaws. People are working on ways to fix the old flaws, such as cgroups.

I don't think a ulimit would be very effective here at preventing denial-of-service. Let's say I set it to 100... I can just have my 100 children each spawn and hold on to 100 children of their own, and so on and so forth. If I just go with a bigger process ID space all these headaches go away, plus existing software works without modification.

[quotemstr]

32 bits is still too small. I wouldn't be comfortable relying on the size of the PID space to avoid collisions until we made it 128 bits or so. I think you're still seriously overestimating the danger of a DoS here: whatever limits apply to forked processes can apply to process handles. Whatever mitigates fork bombs will also mitigate handle-based attacks.

The advantages of process handles outweigh this small risk.

[Dylan16807]

In what scenario would you run out of 64 bit PIDs? How many per second for how many centuries?

[quotemstr]

It's not a matter of running out of PIDs: it's about the probability of accidental collision.

[Dylan16807]

A workable limit is trivial, how about 100 zombie process IDs per user.