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 #116 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: Fri, 5 Sep 2025 01:47:00 +0300

On 04/09/2025 08:18, Eli Zaretskii wrote:

>> This is unfortunately not detailed enough to translate into code.  I've
>> never seen a real-world program which would be vulnerable to this
>> problem, as described here.  I can make up toy programs which meet this
>> description which would hang, but I'm not sure they're actually what
>> you're concerned about.  Especially because they aren't anything like
>> real-world programs.
> 
> I toy program that looks valid and runs in a single-threaded Emacs,
> but hangs or fails when run from a non-main thread is already a
> problem.  Whether it is interesting for us depends on the program.  A
> toy program which demonstrates an issue that real-world programs will
> meet is interesting.

A toy program could be a good example if you can choose a specific one 
and point out how it related to a real program (e.g. being a simplified 
case).

We could take such a program and see whether it indeed exhibits issues 
multi-threaded (when unlocked) but stays reliable in the single threaded 
case and multi-threaded when locked. Both aspects seem testable.

>> Could you give some more details about the scenario, so I can try to
>> write a test demonstrating the problem?  Or could you point to a
>> real-world program which is vulnerable to this problem, so I can turn it
>> into a test?
> 
> I've never used or debugged a real-world program where these aspects
> come into play.  My experience is almost exclusively with small "toy"
> programs and test programs, the ones we have in the test suite and
> also those submitted as part of relevant bug reports.  You may wish
> looking at running the Gnus function that fetches articles from a
> separate thread (I think someone tried that at some point), and you
> may wish talking to Michael Albinus, who tried using threads in Tramp
> (I think he has that on a branch somewhere?).

There two are interesting.

Last I heard, Tramp's branch wasn't stable for everyday use (citing 
hangs, IIRC), but it has a set-process-thread call, locking connection's 
process to thread explicitly:

 
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/tramp.el?h=feature/tramp-thread-safe#n2759

For Gnus, I can't find a branch in Savannah, but Dick Mao's Emacs fork 
claims non-blocking Gnus among features. And it unlocks nnimap's process:

 
https://github.com/commercial-emacs/commercial-emacs/blob/6d3ff0428337a734136d00cf2294aa9d3dbcff0e/lisp/gnus/nnimap.el#L592

Maybe someone could test it out.

Previous Next

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