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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2026, 16:44 UTC
Message-ID: <xmqqfr6mt9uk.fsf@gitster.g>
In-Reply-To: <20260227063118.9069-1-github@paulisageek.com>

Paul Tarjan <paul@paultarjan.com> writes:

Show 5 quoted lines

> 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.