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

[Robert Pluim <rpluim@gmail.com>]

Tassilo Horn <tsdh@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> 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.
>
> I've run with this patch for about a week now and the issue hasn't
> occurred anymore.  So I just pushed it and close the bug report with
> this mail.

What if it was the 'FOR_WRITE' part of the condition that triggered?
Perhaps we should split the 'if'.

Regards

Robert