+ * 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...
