On Tue, Jul 09, 2024 at 12:12:04PM +0300, Heikki Linnakangas wrote: > I thought about it, but no. If the generation number doesn't match, there > are a few possibilities: > > 1. The entry was what we were looking for, but it was concurrently detached. > Return NULL is correct in that case. > > 2. The entry was what we were looking for, but it was concurrently detached, > and was then immediately reattached. NULL is a fine return value in that > case too. When Run runs concurrently with Detach+Attach, you don't get any > guarantee whether the actual apparent order is "Detach, Attach, Run", > "Detach, Run, Attach", or "Run, Detach, Attach". NULL result corresponds to > the "Detach, Run, Attach" ordering. > > 3. The entry was not actually what we were looking for. The name comparison > falsely matched just because the slot was concurrently detached and recycled > for a different injection point. We must continue the search in that case. > > I added a comment to the top of the loop to explain scenario 2. And a > comment to the "continue" to explain scnario 3, because that's a bit subtle.
Okay. I am fine with your arguments here. There is still an argument imo about looping back at the beginning of ActiveInjectionPoints entries if we find an entry with a matching name but the generation does not match with the local copy for the detach-attach concurrent case, but just moving on with the follow-up entries is also OK by me, as well. The new comments in InjectionPointCacheRefresh() are nice improvements. Thanks for that. -- Michael
signature.asc
Description: PGP signature
