On Wed, 2020-08-05 at 10:05 +0800, Ian Kent wrote: > On Tue, 2020-08-04 at 15:56 +0200, Miklos Szeredi wrote: > > On Mon, Aug 03, 2020 at 02:37:50PM +0100, David Howells wrote: > > > Provide support for the handling of an overrun in a watch > > > queue. In the > > > event that an overrun occurs, the watcher needs to be able to > > > find > > > out what > > > it was that they missed. To this end, previous patches added > > > event > > > counters to struct mount. > > > > So this is optimizing the buffer overrun case? > > > > Shoun't we just make sure that the likelyhood of overruns is low > > and > > if it > > happens, just reinitialize everthing from scratch (shouldn't be > > *that* > > expensive). > > But maybe not possible if you are using notifications for tracking > state in user space, you need to know when the thing you have needs > to be synced because you missed something and it's during the > notification processing you actually have the object that may need > to be refreshed. > > > Trying to find out what was missed seems like just adding > > complexity > > for no good > > reason. Coming back to an actual use case. What I said above is one aspect but, since I'm looking at this right now with systemd, and I do have the legacy code to fall back to, the "just reset everything" suggestion does make sense. But I'm struggling to see how I can identify notification buffer overrun in libmount, and overrun is just one possibility for lost notifications, so I like the idea that, as a library user, I can work out that I need to take action based on what I have in the notifications themselves. Ian
