Subject: bug#79201: 30.1.90; set-process-thread can permanently break fd_callback_info slots

From: Eli Zaretskii <[email-masked]>
Date: Mon, 11 Aug 2025 21:09:30 +0300

> From: Spencer Baugh <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>    [email-masked]
> Date: Mon, 11 Aug 2025 13:58:02 -0400
> 
> >> Yes, sorry, I missed that there are two separate mechanisms.  I think
> >> set-process-thread should continue setting the thread member of the
> >> process object, but not the thread member of the fd_callback_info struct.
> >
> > Why not?  set-process-thread can be called when the descriptors for
> > the process are already set up.  That's unlike make-process, which
> > indeed doesn't set the .thread member of the descriptors.
> 
> It's useless and causes this bug.

You ignored my explanation why I think it is not useless.  Please
don't ignore it.  What happens if set-process-thread is called when
the descriptors are already set?

> >> Yes.  Let's just make set-process-thread stop setting the thread member
> >> of the fd_callback_info struct.
> >
> > I don't agree it shouldn't see above.  What problems do you see as the
> > result of that?
> 
> It causes this bug.

Didn't you agree that cleaning up in delete_read_fd and
delete_write_fd solves the problem?  The problem would not exists if
the thread dies before the process exits or is terminated, right?

> Here's an attached patch which makes this change.  The thread member of
> fd_callback_info is then never set, so it can be entirely deleted.

Sorry, I cannot accept such changes without a very good reason.  This
is not some random code or a typo, this stuff was deliberately written
like that, and written for a reason.  If you disagree with the design,
let's first make sure we understand the design and its rationale, and
then please explain why the design is wrong.  It is not enough to show
a single bug, especially if it can be fixed in other ways that don't
remove essential parts of the design.

> This doesn't need an announcement, because the behavior of "calling
> accept-process-output on a process locked to a different thread" still
> works the same way it always did.  There's no (non-bug) user-visible
> change.

Except if set-process-thread is called at some un-opportune moment.