Re: [PATCH 0/2] progress: replace setitimer() with alarm()

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 23, 2025, 21:33 UTC
Message-ID: <xmqq4itxvi3z.fsf@gitster.g>
In-Reply-To: <86bf04c7-6315-46ef-8297-42efc3ed322d@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 9 quoted lines

> We use SIGALRM to raise a flag that tells the progress code to act in
> some way. The progress code does not act asynchronously, but only when
> there is an opportunity to look at the flag, i.e., it acts synchronously
> in response to a third party (SIGALRM) that told it that it's time to
> act.
>
> But we can change the progress code to do the time keeping itself.
> Instead of looking whether a flag was raised, we can let it look at the
> wall clock and check whether an interval has elapsed.

Yes, the use of itimer to only change the flag without doing anything funky has been a very safe way to use signals, doing only absolutely minimal thing in the signal handler. Having to rearm the signal in the signal handler in Carlo's patch made me feel dirtier.

But looking at the wallclock once every iteration of a busy loop?

Operating system folks may have worked hard to minimize the cost of system calls to gettimeofday() in order to help applications that do so, but I somehow feel even dirtier to hear proposal to do so to replace a signal that we set and forget, to be reminded once every second.

I dunno.