gproc:where/1 checks that process is alive before returning value, while gproc:table/0 seems to be do not preform such checking. This introduces a race if process dead and not yet unregistered. So gproc:where(..) could return 'undefined' while process data could appear in gproc:table(). This is rare condition, but i already got it couple of times.
Indeed. Thanks for spotting this. I have pushed a correction for the QLC stuff, and added to the test suite.
The same problem exists for the gproc:select() functions, but I'm not sure I want to fix those. It will be a tradeoff between accuracy and speed, since there is no way to add a liveness check to the match pattern itself. For the QLC queries, I actually added a filter pass, which of course adds to the overhead.
I figured it might be good to retain the choice: fast and loose, or correct - and not quite as fast. :)
Another way to go is of course to add a liveness check in the QLC query itself, when needed... If people feel strongly about this, I can revert. There is no obviously correct answer.
I also fixed another bug I happened to spot when running the test suite.
Given a choice between speed and accuracy, I'd vote for "Yes" :-)
Usually, when speed is critical, we tend to push errors up the user-chain, i.e. false-positives are acceptable and explainable as part of the user-story (Can't find the voicemail even though the user already got notified? just say "it is still being processed, try again later", etc.
Maybe a config parameter "always_check = true|false" or some such?
I added an option, check_pids, to the table/2 generator. By default, it now works as it did before.