From: Junio C Hamano Date: Fri, 24 Jul 2026 20:38:52 GMT Subject: Re: [PATCH] fsmonitor: flush pending FSEvents before cookie wait Message-ID: In-Reply-To: Koji Nakamaru writes: > On Wed, Jul 22, 2026 at 6:05 AM Tamir Duberstein wrote: >> >> 56cef9cb1a (fsmonitor: use pthread_cond_timedwait for cookie wait, >> 2026-04-15) limits the cookie wait to one second so that a filesystem >> which never delivers events cannot hang fsmonitor clients. A client that >> times out receives a trivial response and scans the entire index. >> >> FSEvents can defer delivery while it batches notifications and does not >> guarantee that its queue is drained in one latency interval. A loaded >> macOS system can therefore time out even though the event stream is >> working. >> >> On an Apple M4 Max (16 cores, 128 GiB RAM) running macOS 26.5.2, two >> worktrees with a 1,001,178-entry index timed out 484 of 545 and 297 of >> 365 fsmonitor requests. One status call performed 934,519 lstat() calls >> during a 47-second preload and took 52 seconds overall. >> >> Ask FSEvents to flush pending notifications after creating the cookie >> and before starting the timed wait. Use the asynchronous form because >> the client handler holds main_lock, which the listener callback also >> acquires. Keep the timeout and the behavior of the other backends >> unchanged. >> >> Signed-off-by: Tamir Duberstein >> --- >>... > This patch is carefully designed to minimize any risks. To drain events, > we could also call FSEventStreamFlushSync before acquiring main_lock in > do_handle_client(), but this patch should be sufficient if it mitigates > the issue. The commit message would be much more convincing if you also > included benchmark results showing how many timeouts were reduced. Thanks for a review.