From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 21313@debbugs.gnu.org
Subject: bug#21313: 25.0.50; Strange errors from dbus-handle-event
Date: Tue, 15 Sep 2015 17:37:02 +0200 [thread overview]
Message-ID: <87r3lziti9.fsf@gnu.org> (raw)
In-Reply-To: <877foo4nkd.fsf@gnu.org>
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
next prev parent reply other threads:[~2015-09-15 15:37 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 16:24 bug#21313: 25.0.50; Strange errors from dbus-handle-event Tassilo Horn
2015-09-09 20:43 ` Tassilo Horn
2015-09-11 12:28 ` Tassilo Horn
2015-09-11 12:39 ` Eli Zaretskii
2015-09-11 13:06 ` Tassilo Horn
2015-09-11 13:59 ` Eli Zaretskii
2015-09-15 15:37 ` Tassilo Horn [this message]
2015-09-15 16:01 ` Eli Zaretskii
2015-09-16 11:39 ` Tassilo Horn
2015-09-22 5:49 ` Tassilo Horn
2015-09-22 8:00 ` Robert Pluim
2015-09-22 8:21 ` Tassilo Horn
2015-10-02 18:36 ` Tassilo Horn
2015-10-02 19:05 ` Eli Zaretskii
2015-10-02 20:33 ` Tassilo Horn
2015-10-02 21:10 ` Eli Zaretskii
2015-10-02 21:26 ` Michael Albinus
2015-10-03 5:40 ` Tassilo Horn
2015-10-03 6:32 ` Tassilo Horn
2015-10-03 7:14 ` Eli Zaretskii
2015-10-03 8:10 ` Tassilo Horn
2015-10-03 9:53 ` Eli Zaretskii
2015-10-03 12:06 ` Tassilo Horn
2015-10-03 7:43 ` Michael Albinus
2015-10-03 8:13 ` Tassilo Horn
2015-10-03 9:38 ` Tassilo Horn
2015-10-03 10:53 ` Eli Zaretskii
2015-10-14 9:58 ` Tassilo Horn
2015-10-14 17:05 ` Eli Zaretskii
2015-10-14 19:37 ` Tassilo Horn
2015-10-14 19:43 ` Eli Zaretskii
2015-10-15 11:37 ` Tassilo Horn
2015-10-15 16:56 ` Eli Zaretskii
2015-10-15 17:35 ` Tassilo Horn
2015-10-15 19:44 ` Eli Zaretskii
2015-10-16 4:53 ` Tassilo Horn
2015-10-16 7:02 ` Eli Zaretskii
2015-10-16 7:45 ` Tassilo Horn
2015-10-16 8:23 ` Eli Zaretskii
2015-10-16 9:25 ` Tassilo Horn
2015-10-16 10:11 ` Eli Zaretskii
2015-10-16 10:22 ` Tassilo Horn
2015-10-29 7:43 ` Tassilo Horn
2015-10-29 16:19 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3lziti9.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=21313@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.