Question

1. What is the PID assignment policy in Windows? Repeated runs of a process calling _getpid() indicates non sequential assignment (3548,3344,3628,2748,4872,2360).

2. Given the observed non sequential assignment of PIDs, is it possible for two different process with the same pid to be executed closely in time from one another? Obviously the processes would not be running concurrently.

3. Is it particularly unwise to use a PID in the naming of temporary files?

I’m writing a program that interacts with another executable by generating the required input files, calling the executable, and reading the generated output files from said executable. Upon CLEAN termination the intermediary files are deleted.

My concern is that if the temporary files are not cleaned up and if PIDs are reused there could be an ambiguity between old temporary files that have not been cleaned up and new files. If the executable does not generate a new output file due to an error the old file could appear like the newly created file, thus the error may not be caught.

There are other ways to add robustness such as using a GUID for the temporary files, only using clean directories for temp files, or verifying that there are no files that share the same name as the target output file. Some of these techniques should be employed since PIDs are certain to be repeated upon machine reboot or if the machine is left running for a sufficient amount of time.

The question stems mostly from my curiosity regarding why Windows allocate PIDs in a different manner then *nix.

Answer 1

Using a PID in this manner is problematic. I’ve seen programs that use the PID in conjunction with the current UTC time when naming files so you end up with files named foo_55145_4a3667d3.log. The other option use the FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE options in the dwFlagsAndAttributes parameter to CreateFile().