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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: 21313@debbugs.gnu.org
>> Date: Tue, 15 Sep 2015 17:37:02 +0200
>> 
>> 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.
>
> If no one objects in a week, please push this, and let's see what it
> breaks.

Yes, I'll do.  And I'v Cc-ed Jan in this mail because he's the original
author of that code and probably knows best if that's the right thing to
do.

Bye,
Tassilo