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

Previous Next

Package: emacs;

Reported by: Zhengyi Fu <i <at> fuzy.me>

Date: Tue, 2 Sep 2025 06:21:01 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: i <at> fuzy.me, 79367 <at> debbugs.gnu.org, dmitry <at> gutov.dev
Subject: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t
Date: Fri, 05 Sep 2025 08:54:11 +0300
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: i <at> fuzy.me,  79367 <at> debbugs.gnu.org,  dmitry <at> gutov.dev
> Date: Thu, 04 Sep 2025 15:30:30 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: i <at> fuzy.me,  79367 <at> debbugs.gnu.org,  dmitry <at> gutov.dev
> >> Date: Thu, 04 Sep 2025 12:41:04 -0400
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> We should probably just unconditionally do:
> >> >>   pset_thread (p, ps->thread)
> >> >> here.
> >> >
> >> > That's a bit dangerous, since the I/O descriptors of the new process
> >> > are not yet set, so the call to pset_thread there, in case ps->thread
> >> > is non-nil, would do a partial job.  We could instead move the
> >> > pset_thread call to later, where set_proc_thread is called, but I
> >> > preferred to undo what make_process did ASAP.
> >> 
> >> I'm confused.
> >> 
> >> - It's just duplicating what make_process did, so I expect it's
> >>   essentially a no-op, just simpler code.
> >> 
> >> - Why would it be dangerous even if that wasn't the case?  We're still
> >>   setting up this process, it's not visible to any Lisp code, so what
> >>   bad event could even happen?
> >
> > Having some part of server_accept_connection, even a small part, run
> > with the new process locked to a thread introduces a window during
> > which the process is in an incorrect state, and I would like to avoid
> > that if possible.  Admittedly, in this case the window is very small,
> > but it is still there.  Some future changes could actually trip on
> > that.
> 
> It's already locked to a thread by make_process.

I feel that we are splitting hair, so I went ahead and installed the
last agreed-to version of the patch.




This bug report was last modified 7 days ago.

Previous Next


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