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

From: Paul Tarjan <[email-masked]>
Date: Fri, 27 Feb 2026 17:28:30 -0700

Junio C Hamano <[email-masked]> writes:

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

Yes, that's exactly right. The cookie wait only runs when a client
connects and asks for the current status. The daemon creates a
temporary cookie file, then waits for the listener thread to see the
inotify event for that file. On a quiescent filesystem with no
clients asking, this code path never executes and the timeout never
fires.

So the only time the 1-second timeout can trigger is when a client
is actively waiting for a response and the filesystem isn't
delivering events at all. In that case falling back to a full scan
is the right thing to do since we can't trust the event stream
anyway.

Thanks,
Paul