> > >Maybe I am missing something obvious for injection_points?
> >
> > The point of deferring updating shared stats is to avoid contention. That's certainly crucial for something like
relationaccess. But it seems extremely unlikely that there would be contention due to injection point stat updates.
>
> But, uh, the code is incorrect as-is, due to not locking the shared stats
> while updating them. Which means it's entirely possible to loose stats updates
> if updated by multipole backends. Am I missing something?
yes, and that was going to be my next point. There is no locking while updating,
which is wrong.
Furthermore that flush pending callback,
injection_stats_flush_cb, is not required as we have it
defined. Well, it's required that we define it, but in this case it could
just return true, rather than trying to flush pending data that was
never accumulated.
I think it's better to use ->pending here, since this is referenced
as an example and most real-world cases will likely want to use
->pending for performance reasons.
--
Sami
