GNU bug report logs - #79367
31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t

Previous Next

Full log

Message #38 received at 79367 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: i <at> fuzy.me, 79367 <at> debbugs.gnu.org
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
 diff-hl-update-async is t
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.