I don't know python too much. But if it was done in C/C++, the good practice should be:

1. Create the lock file if it doesn't exit
2. (optional) write down the pid into the file
3. Try lock it. If it failed, read the lock file and report the pid so that the user could know who is using it.

It's ok if the lock file is left behind when the process exited unexpectedly. Because the operating system will auto release the file lock. This is very reliable because the atomicity is guaranteed by the OS.

I don't know python too much. But if it was done in C/C++, the good practice should be:

1. Create the lock file if it doesn't exit
2. (optional) write down the pid into the file
3. Try lock it. If it failed, read the lock file and report the pid so that the user could know who is using it.

It's ok if the lock file is left behind when the process exited unexpectedly. Because the operating system will auto release the file lock. This is very reliable because the atomicity is guaranteed by the OS.

This is a PyTorch CPP+ extension framework which we don't have control. This PR just warns user about a possible issue. There are other scenarios in which this can happen, including several instances running in parallel, in which case we can't delete the lock and it is fine to block to serialize the build process