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

From: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Date: Aug 23, 2025, 19:38 UTC
Message-ID: <ubouc4oefkouvoikedo2lcui3wgjgjovbilxnf67g76gmrp75e@ujkfg5asyy76>
In-Reply-To: <86bf04c7-6315-46ef-8297-42efc3ed322d@kdbg.org>

On Sat, Aug 23, 2025 at 06:24:57PM -0800, Johannes Sixt wrote:

Show 22 quoted lines

> Am 23.08.25 um 15:22 schrieb Carlo Marcelo Arenas Belón via GitGitGadget:
> > The first patch does the minimum changes required to swap the underlying
> > function, but introduce a race condition that is addressed in the second
> > patch.
> > 
> > A third patch that does further changes to the Windows compatibility layer
> > was punted.
> > 
> > Carlo Marcelo Arenas Belón (2): progress: replace setitimer() with alarm()
> > progress: add a shutting down state to the SIGALRM handler
> > 
> After having looked at the progress code for a bit, see this:
> 
> 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.

This is an even better approach indeed, and will lead to an even nicer cleanup in the Windows emulation code.

> A prototype implementation looks like the patch below. It works quite
> well for `git clone` on Linux. I have even lowered the interval to 1/8th
> of a second to get more frequent updates. After a change like this, we
> can remove all the creepy SIGALRM/alarm/setitimer stuff.

Would you mind cleaning it up and making it a patch I could rebase on?, or would you rather finish it off, since you also know the Windows parts better?

Carlo