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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 14 Aug 2025 09:01:13 +0300

> Cc: [email-masked], [email-masked], [email-masked],
>  [email-masked]
> Date: Thu, 14 Aug 2025 07:39:34 +0300
> From: Eli Zaretskii <[email-masked]>
> 
> > That doesn't explain why this is happening, though.  Descriptors are
> > always closed without clearing the .waiting_thread member.  Clearing
> > .waiting_thread is clear_waiting_thread_info's job.  Why isn't it
> > happening?
> 
> clear_waiting_thread_info is called when some thread returns from
> wait_reading_process_output.  If a thread didn't return, but is
> instead stuck in the call to pselect, another thread can run and
> access the descriptors.
> 
> I think if you want to understand exactly how this happens, you need
> to trace the places that close the descriptors.  AFAIU, the scenario
> where make-process reuses a descriptor already marked with
> .waiting_thread of another thread is because that descriptor was
> recently closed.  Otherwise, it's not possible for make-process to get
> a descriptor which is already in use.

And also note that handle_child_signal, which is the SIGCHLD handler,
and is therefore invoked asynchronously, calls delete_read_fd on the
input descriptor of the process that died.  Which might be highly
relevant for your recipe, because it calls "sleep 1", which dies after
1 sec without producing any output.