Race condition when locking Linux processes

[acj]

We've had a couple of reports that locking processes on busy production servers can fail, returning an ESRCH error (no such process). My best guess is that it's related to threads exiting between the calls to self.threads() and thread.lock here, resulting in a lock error. The locking code is tolerant of new threads spinning up during the loop but immediately returns an error if a thread fails to lock.

Would it be acceptable for remoteprocess to log (e.g. debug/warn) failed locks but not return an error? Or to count the number of failed thread locks and only return an error if all of them fail? I'd be happy to make a PR if we can agree on a path.

Downstream issue with repro steps: rbspy/rbspy#334

[benfred]

We should handle the race condition - we're tolerant of new threads being creating during this lock call, and we should also allow threads to exit .

How about we detect the in ESRCH error in thread.lock - and just ignore it ? I'd like to still fail out on permission denied errors, or if there were no threads we managed to lock though.

I'd be happy to accept a PR for this -