+ * See if we have a matching backend. Reading the pss_pid and + * pss_cancel_key fields is racy, a backend might die and remove itself + * from the array at any time. The probability of the cancellation key + * matching wrong process is miniscule, however, so we can live with that. + * PIDs are reused too, so sending the signal based on PID is inherently + * racy anyway, although OS's avoid reusing PIDs too soon.
Just BTW, we know that Windows sometimes recycles PIDs very soon, sometimes even immediately, to the surprise of us Unix hackers. It can make for some very confusing build farm animal logs. My patch will propose to change that particular thing to proc numbers anyway so I'm not asking for a change here, I just didn't want that assumption to go un-footnoted. I suppose that's actually (another) good reason to want to widen the cancellation key, so that we don't have to worry about proc number allocation order being less protective than traditional Unix PID allocation...
