Subject: Re: bug#79334: [PATCH] Don't release thread select lock unnecessarily, [PATCH] Defer closing file descriptors used by other threads

From: Eli Zaretskii <[email-masked]>
Date: Sat, 30 Aug 2025 21:38:52 +0300

> Cc: [email-masked], [email-masked], [email-masked]
> Date: Sat, 30 Aug 2025 19:35:39 +0300
> From: Eli Zaretskii <[email-masked]>
> 
> > >> +	  if (fd_callback_info[fd].waiting_thread == current_thread
> > >> +	      && (fd_callback_info[fd].flags == WAITING_FOR_CLOSE_FD))
> > >> +	    {
> > >> +	      fprintf (stderr, "closing deferred fd %d\n", fd);
> > >> +	      emacs_close (fd);
> > >> +	      /* Ignore any events which happened on this fd. */
> > >> +	      FD_CLR (fd, &Available);
> > >> +	      FD_CLR (fd, &Writeok);
> > >> +	      fd_callback_info[fd].flags = 0;
> > >
> > > Why do it here and not when we deactivate processes?
> > 
> > Because that would close file descriptors that another thread is
> > currently selecting on, causing EBADF.
> 
> No, I mean to deactivate only the processes whose I/O channels are
> locked to the current thread.
> 
> > > Until now we never closed any descriptors inside
> > > wait_reading_process_output.
> > 
> > Just to be clear, we can call deactivate_process from
> > wait_reading_process_output, through status_notify, through process
> > filters, or other similar.  That closes descriptors.
> 
> Yes, and so I suggest doing this logic of deactivating only the
> processes that are locked to the current thread there.

Btw, as a nice bonus of that approach, process sentinel will run in
the context of the thread to which the process is locked.