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

From: Paul Tarjan <paul@paultarjan.com>
Date: Feb 28, 2026, 00:28 UTC
Message-ID: <20260228002830.42676-1-github@paulisageek.com>
In-Reply-To: <xmqqfr6mt9uk.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> 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