Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t

From: Dmitry Gutov <[email-masked]>
Date: Tue, 2 Sep 2025 19:28:05 +0300

On 02/09/2025 18:02, Eli Zaretskii wrote:
>>>> If that doesn't fix it (or you already had that commit), can you try
>>>> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then
>>>> c93be71e45d4cebeb017c813426228e579e9381d and test again?
>>> What will that prove?  Those changes are not going away, so trying
>>> that is just wasting everyone's time and energy.  I thought we were
>>> past that...
>> No, we're not past that, I still think those changes are wrong.
>> Especially because this bug report shows that those changes are indeed
>> breaking existing code.
>>
>> I repeatedly said that those changes would cause new issues to be
>> reported, and now it is happening.  Maybe it doesn't convince you that
>> the changes need to be reverted, but you should at least be giving it a
>> little more credence now.
> This particular breakage is simply because my change was incomplete:
> it left some processes not locked to their thread, and the solution
> proposed by the OP, which fixed that blunder, is simpler and has fewer
> downsides than backing out the process locking to threads.  This
> happens all the time in development, and the conclusion is rarely that
> the original changes should be backed out, certainly not if there are
> simpler fixes.

I do believe that when a change in a long-standing implementation causes 
an immediate issue we first consider reverting, especially when there is 
no consensus on the approach.

A one-liner change is probably not a big deal by itself, but like 
Spencer said, the new process should at least follow the locking of its 
original thread, or something like this. And we still don't have a 
proposed fix on that.

I don't want us to spend a lot of time arguing revert-or-no-revert now, 
but could you, Eli, try to decide on a full example of a buggy scenario 
which is really solved by thread locking being? Like, one that you 
consider a prime example. The present bug report doesn't count, since 
it's caused by an incomplete implementation.

We'll need a specific piece of Lisp code, to be able to try different 
underlying implementations with it.

So far I see two significant reasons to default to locking:

- When we have scheduled some code to run on a different thread 
(filter/sentinel), there is no simple way to switch to a previous 
thread, to run it there. Unlike with the current buffer, for example.
- Enabling locking later if a process starts without being locked to a 
thread, could be error-prone.

But both only really work only if we understand specific problems being 
solved by locking in the first place.