bug#21313: 25.0.50; Strange errors from dbus-handle-event

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, wait_reading_process_output?  Please feel free to ask
> questions about the things you don't understand.
>
> In a nutshell, it waits until one of the input sources has some input,
> and then we read from that source using whatever method is appropriate
> for interpreting that source.

As far as I understand, the file descriptors with pending input are
collected in the fd_set Available, and then this loop gives, e.g., dbus
and inotify handlers a chance to read input from the file descriptors
and convert it to events.

      for (channel = 0; channel <= max_input_desc; ++channel)
        {
          struct fd_callback_data *d = &fd_callback_info[channel];
          if (d->func
              && ((d->condition & FOR_READ
                   && FD_ISSET (channel, &Available))
                  || (d->condition & FOR_WRITE
                      && FD_ISSET (channel, &write_mask))))
            d->func (channel, d->data);
        }

I wondered why channel is not removed from Available here.  I mean,
input was available, and then the handlers registered using add_read_fd
by inotify or dbus consumed the input, so there's probably no input
left.  So I tried this patch

--8<---------------cut here---------------start------------->8---
diff --git a/src/process.c b/src/process.c
index ed5f4c0..7985e37 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5036,7 +5036,10 @@ wait_reading_process_output (intmax_t time_limit, int 
nsecs, int read_kbd,
                   && FD_ISSET (channel, &Available))
                  || (d->condition & FOR_WRITE
                      && FD_ISSET (channel, &write_mask))))
-            d->func (channel, d->data);
+           {
+             d->func (channel, d->data);
+             FD_CLR (channel, &Available);
+           }
        }
 
       for (channel = 0; channel <= max_process_desc; channel++)
--8<---------------cut here---------------end--------------->8---

and since then the problem has not appeared again and I can't see any
obvious other malfunction.  But of course that's really a naive change.
I can grasp the big picture of wait_reading_process_output but not all
the details.

Bye,
Tassilo