Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> Date: Thu, 04 Sep 2025 15:30:30 -0400 >> >> Eli Zaretskii writes: >> >> >> From: Spencer Baugh >> >> Cc: i@fuzy.me, 79367@debbugs.gnu.org, dmitry@gutov.dev >> >> Date: Thu, 04 Sep 2025 12:41:04 -0400 >> >> >> >> Eli Zaretskii 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. I got an assertion failure when testing the latest master.