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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 05 Sep 2025 08:54:11 +0300

> From: Spencer Baugh <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Thu, 04 Sep 2025 15:30:30 -0400
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Spencer Baugh <[email-masked]>
> >> Cc: [email-masked],  [email-masked],  [email-masked]
> >> Date: Thu, 04 Sep 2025 12:41:04 -0400
> >> 
> >> Eli Zaretskii <[email-masked]> 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.