Subject: Re: [PATCH v6 04/10] fsmonitor: use pthread_cond_timedwait for cookie wait

From: Junio C Hamano <[email-masked]>
Date: Fri, 27 Feb 2026 08:44:19 -0800

Paul Tarjan <[email-masked]> writes:

> The 1-second timeout only fires when the filesystem fails to deliver
> the cookie event at all (e.g. overlayfs in containers where inotify
> watches succeed but events never arrive). On a working filesystem
> the cookie event comes back in well under a millisecond, so the
> timeout never triggers.

I am not worried about that case.  When the filesystem is quiescent
and there is absolutely nothing fsmonitor needs to report, wouldn't
we see no "cookie event" delivered at all?

> When it does fire, the client falls back to
> a full scan, which is the safe default.

And if a every-one-second timeout forces somebody to fall back to a
full scan every second, that does not sound like a safe default to
me.

I am clearly missing something here.  Are we handling two different
kind of events, one that wakes us up to expect "cookie" events, and
the other "cookie" events, and we know the delivery of the former is
reliable while the latter not?  So on a quiescent filesystem we do
not even get the first kind of event to wake us up, and we do not
start waiting for "cookie" events with 1-sec timeout in the first
place?  If so, that does sound like a good arrangement.