Reading D-Bus messages

Reading D-Bus messages

[Michael Albinus]

Hi,

D-Bus messages are arriving to Emacs asynchronously. Unfortunately, there
is no trigger mechanism which notifies the arrival of a message; one must
poll for new incoming messages via dbus_connection_read_write().

The call of this method is wrapped by xd_read_queued_messages() of
dbusbind.c, which is called in gobble_input() (see keyboard.c). D-Bus
messages are converted into Emacs events, and stored via
kbd_buffer_store_event().

This works fine, as long as Emacs runs in a window manager. redisplay()
runs periodically, which includes reading the D-Bus messages.

When Emacs is started in a terminal, this does not work anymore. The
input handling seems to wait for keyboard interrupts and alike, and does
NOT poll anymore, whether there are other incoming events.

How shall xd_read_queued_messages() be activated in such a case?

Best regards, Michael.

Re: Reading D-Bus messages

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 12 Aug 2009 11:43:37 +0200, Michael Albinus <michael.albinus@gmx.de> said:

> When Emacs is started in a terminal, this does not work anymore. The
> input handling seems to wait for keyboard interrupts and alike, and
> does NOT poll anymore, whether there are other incoming events.

> How shall xd_read_queued_messages() be activated in such a case?

Usually we monitor file/socket descriptors in such cases.  D-Bus seems
to have a mechanism DBusWatch for this purpose.  Maybe what the GPM
support is doing is helpful.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Reading D-Bus messages

[Michael Albinus]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Usually we monitor file/socket descriptors in such cases.  D-Bus seems
> to have a mechanism DBusWatch for this purpose.

DBusWatch allows you to install handlers. IIUC, those handlers are
called only when dbus_watch_handle() has been applied. File descriptors
are not monitored in the sense, that a handler is called, when there are
incoming messages. This still means polling.

> Maybe what the GPM support is doing is helpful.

Thanks for the hint, I will check the code.

Best regards, Michael.

Re: Reading D-Bus messages

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 12 Aug 2009 12:43:14 +0200, Michael Albinus <michael.albinus@gmx.de> said:

>> Usually we monitor file/socket descriptors in such cases.  D-Bus
>> seems to have a mechanism DBusWatch for this purpose.

> DBusWatch allows you to install handlers. IIUC, those handlers are
> called only when dbus_watch_handle() has been applied. File
> descriptors are not monitored in the sense, that a handler is
> called, when there are incoming messages. This still means polling.

I mentioned DBusWatch because the documentation of
dbus_connection_get_socket/dbus_connection_get_unix_fd says "DO NOT
read or write to the file descriptor, or try to select() on it; use
DBusWatch for main loop integration."  For your purpose, doing
select() on the file/socket descriptor in wait_reading_process_output
(in process.c) is most important.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Reading D-Bus messages

[Michael Albinus]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I mentioned DBusWatch because the documentation of
> dbus_connection_get_socket/dbus_connection_get_unix_fd says "DO NOT
> read or write to the file descriptor, or try to select() on it; use
> DBusWatch for main loop integration."  For your purpose, doing
> select() on the file/socket descriptor in wait_reading_process_output
> (in process.c) is most important.

I've written a function xd_pending_messages, which uses internally
dbus_connection_get_dispatch_status. By this I could avoid select() on
the file descriptor. D-Bus messages are now received without keyboard
input, also when Emacs runs in terminal mode. However, there is a delay
of some seconds.

xd_pending_messages is called in readable_events, which means that it is
checked inside wait_reading_process_output. Is there a possibility to
trigger a more frequent check via detect_input_pending?

Best regards, Michael.

Re: Reading D-Bus messages

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 15 Aug 2009 21:16:54 +0200, Michael Albinus <michael.albinus@gmx.de> said:

> I've written a function xd_pending_messages, which uses internally
> dbus_connection_get_dispatch_status. By this I could avoid select()
> on the file descriptor. D-Bus messages are now received without
> keyboard input, also when Emacs runs in terminal mode. However,
> there is a delay of some seconds.

> xd_pending_messages is called in readable_events, which means that
> it is checked inside wait_reading_process_output. Is there a
> possibility to trigger a more frequent check via
> detect_input_pending?

While Emacs is idle, it blocks at the select() call in
wait_reading_process_output waiting for one of the several kinds of
events to happen: window-system events, subprocess output arrivals,
socket status changes, signal arrivals, and timer expirations.  That's
why it is important to have a file/socket descriptor to monitor for
D-Bus in order to avoid consuming CPU time for polling.

As far as I browsed some D-Bus documents,
dbus_connection_set_watch_functions seems to have something to do with
this.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Reading D-Bus messages

[Michael Albinus]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:


> While Emacs is idle, it blocks at the select() call in
> wait_reading_process_output waiting for one of the several kinds of
> events to happen: window-system events, subprocess output arrivals,
> socket status changes, signal arrivals, and timer expirations.  That's
> why it is important to have a file/socket descriptor to monitor for
> D-Bus in order to avoid consuming CPU time for polling.

Finally, it was sufficient to add the D-Bus file descriptors via
add_keyboard_wait_descriptor. Thanks for pushing me into the right
direction!

> As far as I browsed some D-Bus documents,
> dbus_connection_set_watch_functions seems to have something to do with
> this.

DBusWatch uses its own select() loop. So it seems to be better to avoid it.

Mario, could you, please, check whether it works for you?

Best regards, Michael.

Re: Reading D-Bus messages

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 16 Aug 2009 14:30:54 +0200, Michael Albinus <michael.albinus@gmx.de> said:

> Finally, it was sufficient to add the D-Bus file descriptors via
> add_keyboard_wait_descriptor. Thanks for pushing me into the right
> direction!

But again, the documentation of
dbus_connection_get_socket/dbus_connection_get_unix_fd says "DO NOT
read or write to the file descriptor, or try to select() on it; use
DBusWatch for main loop integration."  What you want to do is actually
a kind of "main loop integration", though it looks a bit different
from those in typical GUI toolkits.

Actually, I'm not sure how the above caveat is serious/critical.
Maybe you can ask at some D-Bus list.

>> As far as I browsed some D-Bus documents,
>> dbus_connection_set_watch_functions seems to have something to do
>> with this.

> DBusWatch uses its own select() loop. So it seems to be better to
> avoid it.

Perhaps you are looking at the code of the default (or sample)
implementation of the "main loop integration"?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Reading D-Bus messages

[Daniel Pittman]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>>>> On Sun, 16 Aug 2009 14:30:54 +0200, Michael Albinus <michael.albinus@gmx.de> said:
>
>> Finally, it was sufficient to add the D-Bus file descriptors via
>> add_keyboard_wait_descriptor. Thanks for pushing me into the right
>> direction!
>
> But again, the documentation of
> dbus_connection_get_socket/dbus_connection_get_unix_fd says "DO NOT read or
> write to the file descriptor, or try to select() on it; use DBusWatch for
> main loop integration."  What you want to do is actually a kind of "main
> loop integration", though it looks a bit different from those in typical GUI
> toolkits.

http://dbus.freedesktop.org/doc/api/html/group__DBusWatch.html#g436561729dce54092d8874f38f71308b

The mechanism you want is 'dbus_watch_get_socket', akin to:

    DBusWatch *watch = ...;
    /* TODO: Reverse these on Win32, which prefers the opposite. */
    int socket = dbus_watch_get_unix_fd(watch)
    if (socket == -1) {
        socket = dbus_watch_get_socket(watch);
        if (socket == -1) { abort("can't cope, off to mordor"); }
    }

Then, attach the socket returned from the DBusWatch subsystem to select on.
Presumably this allows the DBus system to abstract away the raw socket
connection and the watch connection, so the former can change without
perturbing the later.

Regards,
        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons
   Looking for work?  Love Perl?  In Melbourne, Australia?  We are hiring.

Re: Reading D-Bus messages

[Michael Albinus]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Sun, 16 Aug 2009 14:30:54 +0200, Michael Albinus <michael.albinus@gmx.de> said:
>
>> Finally, it was sufficient to add the D-Bus file descriptors via
>> add_keyboard_wait_descriptor. Thanks for pushing me into the right
>> direction!
>
> But again, the documentation of
> dbus_connection_get_socket/dbus_connection_get_unix_fd says "DO NOT
> read or write to the file descriptor, or try to select() on it; use
> DBusWatch for main loop integration."  What you want to do is actually
> a kind of "main loop integration", though it looks a bit different
> from those in typical GUI toolkits.
>
> Actually, I'm not sure how the above caveat is serious/critical.
> Maybe you can ask at some D-Bus list.

I confess that the documentation sounds dramatic. That's why I've
rewritten it, using DBusWatch objects. This works pretty well, too.

Thanks, also to Daniel (whose code I have stolen), and best regards, Michael.

Reading D-Bus messages

[Michael Albinus]

Hi,

I'm trying to make Emacs' D-Bus bindings running also in a cygwin
environment. Synchronous D-Bus messages are handled fine.

The problem is reading asynchronous messages. dbusbind.c offers two
functions: xd_pending_messages (called in readable_events), which
returns TRUE when there are D-Bus messages to be read, and
xd_read_queued_messages (called in gobble_input), which reads the
message(s). That works OK on GNU/Linux (and other systems, I haven't
tested myself).

With cygwin, after the first time a D-Bus message has arrived, and
xd_pending_messages has returned TRUE, Emacs is blocked. According to
the traces, xd_pending_messages is called again and again, and
xd_pending_messages isn't called ever.

I do not understand all details of keyboard.c. Is there something I need
to set in order to urge the call of xd_read_queued_messages (via
gobble_input)? Or do I need to suppress further polling? What is the
difference for Emacs running with cygwin, compared with the GNU/Linux case?

Btw, when I call xd_read_queued_messages inside xd_pending_messages,
everything works fine also with cygwin. But I guess this isn't the
correct solution.

Thanks, and best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

Hi Michael,

On 9/22/2010 9:18 AM, Michael Albinus wrote:
> Hi,
>
> I'm trying to make Emacs' D-Bus bindings running also in a cygwin
> environment. Synchronous D-Bus messages are handled fine.
>
> The problem is reading asynchronous messages. dbusbind.c offers two
> functions: xd_pending_messages (called in readable_events), which
> returns TRUE when there are D-Bus messages to be read, and
> xd_read_queued_messages (called in gobble_input), which reads the
> message(s). That works OK on GNU/Linux (and other systems, I haven't
> tested myself).
>
> With cygwin, after the first time a D-Bus message has arrived, and
> xd_pending_messages has returned TRUE, Emacs is blocked. According to
> the traces, xd_pending_messages is called again and again, and
> xd_pending_messages isn't called ever.
>
> I do not understand all details of keyboard.c. Is there something I need
> to set in order to urge the call of xd_read_queued_messages (via
> gobble_input)? Or do I need to suppress further polling? What is the
> difference for Emacs running with cygwin, compared with the GNU/Linux case?
>
> Btw, when I call xd_read_queued_messages inside xd_pending_messages,
> everything works fine also with cygwin. But I guess this isn't the
> correct solution.

I don't know enough to attempt an answer.  Is there any chance you could 
write a small self-contained program that exhibits the problem?  If so, 
there's a chance someone on the Cygwin list could help.

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> Hi Michael,

Hi Ken,

>> I do not understand all details of keyboard.c. Is there something I need
>> to set in order to urge the call of xd_read_queued_messages (via
>> gobble_input)? Or do I need to suppress further polling? What is the
>> difference for Emacs running with cygwin, compared with the GNU/Linux case?
>>
>> Btw, when I call xd_read_queued_messages inside xd_pending_messages,
>> everything works fine also with cygwin. But I guess this isn't the
>> correct solution.
>
> I don't know enough to attempt an answer.  Is there any chance you
> could write a small self-contained program that exhibits the problem?
> If so, there's a chance someone on the Cygwin list could help.

The problem seems to be how gobble_input is called in kbd_buffer_get_event
(keyboard.c):

/* Note SIGIO has been undef'd if FIONREAD is missing.  */
#ifdef SIGIO
      gobble_input (0);
#endif /* SIGIO */

SIGIO is undefined, and gobble_input is not called under cygwin
therefore. If I remove this conditional directive, D-Bus connections in
Emacs work fine! What is the reason, that SIGIO is undefined under cygwin?

> Ken

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

[For the moment I'm leaving out the cygwin list, because I think I see 
the problem.]

On 9/23/2010 3:19 AM, Michael Albinus wrote:
> Ken Brown<kbrown@cornell.edu>  writes:
>
>> Hi Michael,
>
> Hi Ken,
>
>>> I do not understand all details of keyboard.c. Is there something I need
>>> to set in order to urge the call of xd_read_queued_messages (via
>>> gobble_input)? Or do I need to suppress further polling? What is the
>>> difference for Emacs running with cygwin, compared with the GNU/Linux case?
>>>
>>> Btw, when I call xd_read_queued_messages inside xd_pending_messages,
>>> everything works fine also with cygwin. But I guess this isn't the
>>> correct solution.
>>
>> I don't know enough to attempt an answer.  Is there any chance you
>> could write a small self-contained program that exhibits the problem?
>> If so, there's a chance someone on the Cygwin list could help.
>
> The problem seems to be how gobble_input is called in kbd_buffer_get_event
> (keyboard.c):
>
> /* Note SIGIO has been undef'd if FIONREAD is missing.  */
> #ifdef SIGIO
>        gobble_input (0);
> #endif /* SIGIO */
>
> SIGIO is undefined, and gobble_input is not called under cygwin
> therefore. If I remove this conditional directive, D-Bus connections in
> Emacs work fine! What is the reason, that SIGIO is undefined under cygwin?

Grepping /usr/include, I see that SIGIO (and FIONREAD) seem to be 
defined.  So I think the trouble must be that these get undefined in the 
emacs build, perhaps because of the '#undef INTERRUPT_INPUT' in 
src/s/cygwin.h.  I changed it to '#define INTERRUPT_INPUT' and rebuilt, 
but dbus still didn't work.  I'm in the process of bootstrapping right 
now so I can try again.  I don't understand the build process well 
enough to know whether bootstrapping should be necessary after this change.

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> Grepping /usr/include, I see that SIGIO (and FIONREAD) seem to be 
> defined.  So I think the trouble must be that these get undefined in the 
> emacs build, perhaps because of the '#undef INTERRUPT_INPUT' in 
> src/s/cygwin.h.  I changed it to '#define INTERRUPT_INPUT' and rebuilt, 
> but dbus still didn't work.  I'm in the process of bootstrapping right 
> now so I can try again.  I don't understand the build process well 
> enough to know whether bootstrapping should be necessary after this change.

Same here, even after a bootstrap. For the time being I use

#if defined (SIGIO) || defined (CYGWIN)
      gobble_input (0);
#endif /* SIGIO */

But this is ugly, and it shouldn't be the final solution.

> Ken

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/23/2010 9:42 AM, Michael Albinus wrote:
> Ken Brown<kbrown@cornell.edu>  writes:
>
>> Grepping /usr/include, I see that SIGIO (and FIONREAD) seem to be
>> defined.  So I think the trouble must be that these get undefined in the
>> emacs build, perhaps because of the '#undef INTERRUPT_INPUT' in
>> src/s/cygwin.h.  I changed it to '#define INTERRUPT_INPUT' and rebuilt,
>> but dbus still didn't work.  I'm in the process of bootstrapping right
>> now so I can try again.  I don't understand the build process well
>> enough to know whether bootstrapping should be necessary after this change.
>
> Same here, even after a bootstrap. For the time being I use
>
> #if defined (SIGIO) || defined (CYGWIN)
>        gobble_input (0);
> #endif /* SIGIO */
>
> But this is ugly, and it shouldn't be the final solution.

I was wrong about SIGIO being defined in Cygwin.  (I was careless in my 
grepping and didn't look closely enough at the header files.)  And an 
answer just appeared on the Cygwin list, saying that SIGIO is undefined 
because the functionality is not implemented.

So now the question is just finding the best way to deal with this.  Do 
you understand why gobble_input is called only if SIGIO is defined?

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> I was wrong about SIGIO being defined in Cygwin.  (I was careless in
> my grepping and didn't look closely enough at the header files.)  And
> an answer just appeared on the Cygwin list, saying that SIGIO is
> undefined because the functionality is not implemented.
>
> So now the question is just finding the best way to deal with this.
> Do you understand why gobble_input is called only if SIGIO is defined?

Don't know. ChangeLog.1 says:

1986-01-23  Richard M. Stallman  (rms@prep)

            * dispnew.c (Fsit_for):
            Call gobble_input only if SIGIO exists.

1985-11-01  Richard M. Stallman  (rms@prep)

            * keyboard.c (gobble_input, input_available_signal,
              kbd_buffer_store_char):
              Make these functions exist only if SIGIO is defined.

1985-10-16  Richard M. Stallman  (rms@mit-prep)

            * keyboard.c:
            Get error instead of croaking if want to send SIGTSTP.
            Get compile time error in gobble_input if SIGIO is not
            defined.

> Ken

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/23/2010 10:46 AM, Michael Albinus wrote:
> Ken Brown<kbrown@cornell.edu>  writes:
>
>> I was wrong about SIGIO being defined in Cygwin.  (I was careless in
>> my grepping and didn't look closely enough at the header files.)  And
>> an answer just appeared on the Cygwin list, saying that SIGIO is
>> undefined because the functionality is not implemented.
>>
>> So now the question is just finding the best way to deal with this.
>> Do you understand why gobble_input is called only if SIGIO is defined?
>
> Don't know. ChangeLog.1 says:
>
> 1986-01-23  Richard M. Stallman  (rms@prep)
>
>              * dispnew.c (Fsit_for):
>              Call gobble_input only if SIGIO exists.
>
> 1985-11-01  Richard M. Stallman  (rms@prep)
>
>              * keyboard.c (gobble_input, input_available_signal,
>                kbd_buffer_store_char):
>                Make these functions exist only if SIGIO is defined.
>
> 1985-10-16  Richard M. Stallman  (rms@mit-prep)
>
>              * keyboard.c:
>              Get error instead of croaking if want to send SIGTSTP.
>              Get compile time error in gobble_input if SIGIO is not
>              defined.

Well, I'll just try it for a while and see if I notice any problems as a 
result of using gobble_input without SIGIO.  If not, I'll upload a new 
Cygwin test release and see what happens.

Thank you very much for all the time and effort you put into this.

Best regards,

Ken

Re: Reading D-Bus messages

[Eli Zaretskii]

> Date: Thu, 23 Sep 2010 16:49:32 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> >> Do you understand why gobble_input is called only if SIGIO is defined?
> >
> > Don't know. ChangeLog.1 says:
> >
> > 1986-01-23  Richard M. Stallman  (rms@prep)
> >
> >              * dispnew.c (Fsit_for):
> >              Call gobble_input only if SIGIO exists.
> >
> > 1985-11-01  Richard M. Stallman  (rms@prep)
> >
> >              * keyboard.c (gobble_input, input_available_signal,
> >                kbd_buffer_store_char):
> >                Make these functions exist only if SIGIO is defined.
> >
> > 1985-10-16  Richard M. Stallman  (rms@mit-prep)
> >
> >              * keyboard.c:
> >              Get error instead of croaking if want to send SIGTSTP.
> >              Get compile time error in gobble_input if SIGIO is not
> >              defined.
> 
> Well, I'll just try it for a while and see if I notice any problems as a 
> result of using gobble_input without SIGIO.  If not, I'll upload a new 
> Cygwin test release and see what happens.

I'd rather turn the table and ask why is the call to
xd_read_queued_messages made in gobble_input and not elsewhere?  Why
are we mixing input from D-Bus with keyboard input?  And why in
gobble_input?

Re: Reading D-Bus messages

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd rather turn the table and ask why is the call to
> xd_read_queued_messages made in gobble_input and not elsewhere?  Why
> are we mixing input from D-Bus with keyboard input?  And why in
> gobble_input?

D-Bus messages arrive asynchronously. xd_read_queued_messages() converts
them into special events, which are stored via kbd_buffer_store_event().

gobble_input() is used, because it is called at several places, for
instance in sit_for(), kbd_buffer_get_event(), get_input_pending(),
ns_select() - D-Bus messages shall be handled as soon as they arrive.

Best regards, Michael.

Re: Reading D-Bus messages

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Ken Brown <kbrown@cornell.edu>,  emacs-devel@gnu.org
> Date: Fri, 24 Sep 2010 08:30:21 +0200
> 
> D-Bus messages shall be handled as soon as they arrive.

Why?  How is it different from input handled by
wait_reading_process_output (via `select' etc.)?

In any case, putting D-Bus messages into the keyboard buffer doesn't
ensure they will be handled instantly, if lots of previous input is
waiting in the queue.

Re: Reading D-Bus messages

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> D-Bus messages shall be handled as soon as they arrive.
>
> Why?  How is it different from input handled by
> wait_reading_process_output (via `select' etc.)?
>
> In any case, putting D-Bus messages into the keyboard buffer doesn't
> ensure they will be handled instantly, if lots of previous input is
> waiting in the queue.

I do not know too much how process output is handled.

D-Bus messages are handled as special events (like frame events or mouse
events) in `special-event-map'. It would be sufficient to handle them
similar.

Whether this is in gobble_input or somewhere else, I do not care.

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/23/2010 5:03 PM, Eli Zaretskii wrote:
>> Date: Thu, 23 Sep 2010 16:49:32 -0400
>> From: Ken Brown<kbrown@cornell.edu>
>> Cc: emacs-devel<emacs-devel@gnu.org>
>>
>>>> Do you understand why gobble_input is called only if SIGIO is defined?
>>>
>>> Don't know. ChangeLog.1 says:
>>>
>>> 1986-01-23  Richard M. Stallman  (rms@prep)
>>>
>>>               * dispnew.c (Fsit_for):
>>>               Call gobble_input only if SIGIO exists.
>>>
>>> 1985-11-01  Richard M. Stallman  (rms@prep)
>>>
>>>               * keyboard.c (gobble_input, input_available_signal,
>>>                 kbd_buffer_store_char):
>>>                 Make these functions exist only if SIGIO is defined.
>>>
>>> 1985-10-16  Richard M. Stallman  (rms@mit-prep)
>>>
>>>               * keyboard.c:
>>>               Get error instead of croaking if want to send SIGTSTP.
>>>               Get compile time error in gobble_input if SIGIO is not
>>>               defined.
>>
>> Well, I'll just try it for a while and see if I notice any problems as a
>> result of using gobble_input without SIGIO.  If not, I'll upload a new
>> Cygwin test release and see what happens.
>
> I'd rather turn the table and ask why is the call to
> xd_read_queued_messages made in gobble_input and not elsewhere?  Why
> are we mixing input from D-Bus with keyboard input?  And why in
> gobble_input?

Regardless of what decision is ultimately made about these questions, 
I'd still like to know why one (and only one) of the calls to 
gobble_input in keyboard.c is made only if SIGIO is defined.  Is this 
something that was needed in 1985 and is no longer relevant?

Ken

Re: Reading D-Bus messages

[Eli Zaretskii]

> Date: Fri, 24 Sep 2010 09:20:45 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: emacs-devel <emacs-devel@gnu.org>
> 
> Regardless of what decision is ultimately made about these questions, 
> I'd still like to know why one (and only one) of the calls to 
> gobble_input in keyboard.c is made only if SIGIO is defined.

Because SIGIO means input is interrupt-driven, and therefore can
arrive asynchronously, by raising an interrupt and invoking the
interrupt handler.  The other possibilities are synchronous, and
therefore don't need to be checked more than once in a loop.

Re: Reading D-Bus messages

[Jan Djärv]

2010-09-24 08:30, Michael Albinus skrev:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>> I'd rather turn the table and ask why is the call to
>> xd_read_queued_messages made in gobble_input and not elsewhere?  Why
>> are we mixing input from D-Bus with keyboard input?  And why in
>> gobble_input?
>
> D-Bus messages arrive asynchronously. xd_read_queued_messages() converts
> them into special events, which are stored via kbd_buffer_store_event().
>
> gobble_input() is used, because it is called at several places, for
> instance in sit_for(), kbd_buffer_get_event(), get_input_pending(),
> ns_select() - D-Bus messages shall be handled as soon as they arrive.
>

This is overkill.  Not even X messages are processed this fast.
Checking for D-bus messages when the input loop is entered should be enough.

	Jan D.

Re: Reading D-Bus messages

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 2010-09-24 08:30, Michael Albinus skrev:
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>
>>> I'd rather turn the table and ask why is the call to
>>> xd_read_queued_messages made in gobble_input and not elsewhere?  Why
>>> are we mixing input from D-Bus with keyboard input?  And why in
>>> gobble_input?
>>
>> D-Bus messages arrive asynchronously. xd_read_queued_messages() converts
>> them into special events, which are stored via kbd_buffer_store_event().
>>
>> gobble_input() is used, because it is called at several places, for
>> instance in sit_for(), kbd_buffer_get_event(), get_input_pending(),
>> ns_select() - D-Bus messages shall be handled as soon as they arrive.
>
> This is overkill.  Not even X messages are processed this fast.
> Checking for D-bus messages when the input loop is entered should be enough.

Yep, would be sufficient to get them the same rate as X events, for
example. Somebody, who knows keyboard.c better than I do, could move the
xd_read_queued_messages() call to an appropriate place. Maybe just
inside kbd_buffer_get_event() ?

Handling D-Bus messages like process output would not be reasonable,
because one needs to requests this via accept-process-output. And there
is no related process.

> 	Jan D.

Best regards, Michael.

Re: Reading D-Bus messages

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, Ken Brown <kbrown@cornell.edu>,
>         "emacs-devel\@gnu.org" <emacs-devel@gnu.org>
> Date: Fri, 24 Sep 2010 17:10:14 +0200
> 
> Handling D-Bus messages like process output would not be reasonable,
> because one needs to requests this via accept-process-output. And there
> is no related process.

I didn't say like process output, I said inside
wait_reading_process_output.  That function does more than just read
process output, please take a look.

Re: Reading D-Bus messages

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Ken Brown <kbrown@cornell.edu>,
>>         "emacs-devel\@gnu.org" <emacs-devel@gnu.org>
>> Date: Fri, 24 Sep 2010 17:10:14 +0200
>> 
>> Handling D-Bus messages like process output would not be reasonable,
>> because one needs to requests this via accept-process-output. And there
>> is no related process.
>
> I didn't say like process output, I said inside
> wait_reading_process_output.  That function does more than just read
> process output, please take a look.

Looks promising. Over the weekend, I'll try to write an own xd_select, and 
to call it there. I will take xg_select as example to steal code from :-)

Best regards, Michael.

Re: Reading D-Bus messages

[Jan Djärv]

Michael Albinus skrev 2010-09-24 23.11:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>>> From: Michael Albinus<michael.albinus@gmx.de>
>>> Cc: Eli Zaretskii<eliz@gnu.org>, Ken Brown<kbrown@cornell.edu>,
>>>          "emacs-devel\@gnu.org"<emacs-devel@gnu.org>
>>> Date: Fri, 24 Sep 2010 17:10:14 +0200
>>>
>>> Handling D-Bus messages like process output would not be reasonable,
>>> because one needs to requests this via accept-process-output. And there
>>> is no related process.
>>
>> I didn't say like process output, I said inside
>> wait_reading_process_output.  That function does more than just read
>> process output, please take a look.
>
> Looks promising. Over the weekend, I'll try to write an own xd_select, and
> to call it there. I will take xg_select as example to steal code from :-)
>

No, please don't, you have total control over your filed escriptors  xg_select 
was done because file descriptors are handeled outside of Emacs control.

We should have a general way to add file descriptors and get a callback for 
them.  In the mean time, do something like this in process.c:

static SELECT_TYPE dbus_mask;

void
add_dbus_fd (int fd)
{
   FD_SET (fd, &dbus_mask);
   add_keyboard_wait_descriptor (fd);
}

void
remove_dbus_fd (int fd)
{
   FD_CLR (fd, &dbus_mask);
   remove_keyboard_wait_descriptor (fd);
}

After this wait_reading_process_output

       /* Check for data from a process.  */
       if (no_avail || nfds == 0)
	continue;

add
       for (channel = 0; channel <= max_keyboard_desc; ++channel)
	 if (FD_ISSET (channel, &dbus_mask) && FD_ISSET (channel, &Available))
             {
                  xd_read_queued_messages ();
                  break; /* All dbus channels has been read, exit loop */
             }

and in init_process:

       FD_ZERO (&dbus_mask);


Use remove_dbus_fd and add_dbus_fd in dbusbind.c.
But maybe I'll add that general input mechanism instead, well see.

	Jan D.

Re: Reading D-Bus messages

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

> We should have a general way to add file descriptors and get a
> callback for them.  In the mean time, do something like this in
> process.c:
>
> static SELECT_TYPE dbus_mask;
>
> void
> add_dbus_fd (int fd)
> {
>   FD_SET (fd, &dbus_mask);
>   add_keyboard_wait_descriptor (fd);
> }
>
> void
> remove_dbus_fd (int fd)
> {
>   FD_CLR (fd, &dbus_mask);
>   remove_keyboard_wait_descriptor (fd);
> }
>
> After this wait_reading_process_output
>
>       /* Check for data from a process.  */
>       if (no_avail || nfds == 0)
> 	continue;
>
> add
>       for (channel = 0; channel <= max_keyboard_desc; ++channel)
> 	 if (FD_ISSET (channel, &dbus_mask) && FD_ISSET (channel, &Available))
>             {
>                  xd_read_queued_messages ();
>                  break; /* All dbus channels has been read, exit loop */
>             }
>
> and in init_process:
>
>       FD_ZERO (&dbus_mask);
>
> Use remove_dbus_fd and add_dbus_fd in dbusbind.c.
> But maybe I'll add that general input mechanism instead, well see.

I have added this, and it works fine in an X11 environment. I guess,
redisplay() does the job.

If I test it in a non-X11 terminal, arriving D-Bus messages are
recognised only after pressing a character on the keyboard. So at least
an additional trigger is missing to handle this event in time.

> 	Jan D.

Best regards, Michael.

Re: Reading D-Bus messages

[Jan Djärv]

Michael Albinus skrev 2010-09-25 18.52:

>
> I have added this, and it works fine in an X11 environment. I guess,
> redisplay() does the job.
>

No, it has nothing to do with redisplay.

> If I test it in a non-X11 terminal, arriving D-Bus messages are
> recognised only after pressing a character on the keyboard. So at least
> an additional trigger is missing to handle this event in time.
>

This sounds like a bug.  I'll have a look.  Is this the same emacs binary for 
X and non-X you are running?
I don't understand why there is #ifdef subprocess around 
add/delete_keyboard_wait_descriptor, but it should not matter.
	Jan D.

Re: Reading D-Bus messages

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> If I test it in a non-X11 terminal, arriving D-Bus messages are
>> recognised only after pressing a character on the keyboard. So at least
>> an additional trigger is missing to handle this event in time.
>
> This sounds like a bug.  I'll have a look.  Is this the same emacs
> binary for X and non-X you are running?

Yes.

> I don't understand why there is #ifdef subprocess around
> add/delete_keyboard_wait_descriptor, but it should not matter.

For testing, I use the example in (info "(dbus) Receiving Method Calls")
In the non-X test case, you must call dbus-send from another terminal,
with the same $DBUS_SESSION_BUS_ADDRESS set.

> 	Jan D.

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/25/2010 12:52 PM, Michael Albinus wrote:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> We should have a general way to add file descriptors and get a
>> callback for them.  In the mean time, do something like this in
>> process.c:
>>
>> static SELECT_TYPE dbus_mask;
>>
>> void
>> add_dbus_fd (int fd)
>> {
>>    FD_SET (fd,&dbus_mask);
>>    add_keyboard_wait_descriptor (fd);
>> }
>>
>> void
>> remove_dbus_fd (int fd)
>> {
>>    FD_CLR (fd,&dbus_mask);
>>    remove_keyboard_wait_descriptor (fd);
>> }
>>
>> After this wait_reading_process_output
>>
>>        /* Check for data from a process.  */
>>        if (no_avail || nfds == 0)
>> 	continue;
>>
>> add
>>        for (channel = 0; channel<= max_keyboard_desc; ++channel)
>> 	 if (FD_ISSET (channel,&dbus_mask)&&  FD_ISSET (channel,&Available))
>>              {
>>                   xd_read_queued_messages ();
>>                   break; /* All dbus channels has been read, exit loop */
>>              }
>>
>> and in init_process:
>>
>>        FD_ZERO (&dbus_mask);
>>
>> Use remove_dbus_fd and add_dbus_fd in dbusbind.c.
>> But maybe I'll add that general input mechanism instead, well see.
>
> I have added this, and it works fine in an X11 environment. I guess,
> redisplay() does the job.
>
> If I test it in a non-X11 terminal, arriving D-Bus messages are
> recognised only after pressing a character on the keyboard. So at least
> an additional trigger is missing to handle this event in time.

Where can I find your changes?  I'd like to test it in Cygwin.  I tried 
to make the changes Jan suggested myself, but I found that emacs was 
blocked after I loaded dbus.el, just as before.  I probably did 
something wrong.

Ken

Re: Reading D-Bus messages

[Ken Brown]

On 9/25/2010 5:46 PM, Ken Brown wrote:
> On 9/25/2010 12:52 PM, Michael Albinus wrote:
>> Jan Djärv<jan.h.d@swipnet.se>   writes:
>>
>>> We should have a general way to add file descriptors and get a
>>> callback for them.  In the mean time, do something like this in
>>> process.c:
>>>
>>> static SELECT_TYPE dbus_mask;
>>>
>>> void
>>> add_dbus_fd (int fd)
>>> {
>>>     FD_SET (fd,&dbus_mask);
>>>     add_keyboard_wait_descriptor (fd);
>>> }
>>>
>>> void
>>> remove_dbus_fd (int fd)
>>> {
>>>     FD_CLR (fd,&dbus_mask);
>>>     remove_keyboard_wait_descriptor (fd);
>>> }
>>>
>>> After this wait_reading_process_output
>>>
>>>         /* Check for data from a process.  */
>>>         if (no_avail || nfds == 0)
>>> 	continue;
>>>
>>> add
>>>         for (channel = 0; channel<= max_keyboard_desc; ++channel)
>>> 	 if (FD_ISSET (channel,&dbus_mask)&&   FD_ISSET (channel,&Available))
>>>               {
>>>                    xd_read_queued_messages ();
>>>                    break; /* All dbus channels has been read, exit loop */
>>>               }
>>>
>>> and in init_process:
>>>
>>>         FD_ZERO (&dbus_mask);
>>>
>>> Use remove_dbus_fd and add_dbus_fd in dbusbind.c.
>>> But maybe I'll add that general input mechanism instead, well see.
>>
>> I have added this, and it works fine in an X11 environment. I guess,
>> redisplay() does the job.
>>
>> If I test it in a non-X11 terminal, arriving D-Bus messages are
>> recognised only after pressing a character on the keyboard. So at least
>> an additional trigger is missing to handle this event in time.
>
> Where can I find your changes?  I'd like to test it in Cygwin.  I tried
> to make the changes Jan suggested myself, but I found that emacs was
> blocked after I loaded dbus.el, just as before.  I probably did
> something wrong.

OK, I've got it working now.  (I had to remove the call to 
xd_pending_messages in keyboard.c; I'm not sure if that's the right 
thing to do or not.)  And I now observe the same thing as you: 
Everything I tried worked under X11, but messages were delayed when 
running in a non-X11 terminal.

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> OK, I've got it working now.  (I had to remove the call to
> xd_pending_messages in keyboard.c; I'm not sure if that's the right
> thing to do or not.)

That's correct. Both xd_pending_messages() and xd_read_queued_messages()
calls must be removed in keyboard.c

Best regards, Michael.

Re: Reading D-Bus messages

[Jan Djärv]

Michael Albinus skrev 2010-09-25 22.54:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>>> If I test it in a non-X11 terminal, arriving D-Bus messages are
>>> recognised only after pressing a character on the keyboard. So at least
>>> an additional trigger is missing to handle this event in time.
>>
>> This sounds like a bug.  I'll have a look.  Is this the same emacs
>> binary for X and non-X you are running?
>
> Yes.
>
>> I don't understand why there is #ifdef subprocess around
>> add/delete_keyboard_wait_descriptor, but it should not matter.
>
> For testing, I use the example in (info "(dbus) Receiving Method Calls")
> In the non-X test case, you must call dbus-send from another terminal,
> with the same $DBUS_SESSION_BUS_ADDRESS set.
>

Ok, I checked in several changes.  There where at least two bugs.
First dbusbind didn't process all messages, just one.  So things didn't work 
well when DBUS had read more than one message into its queue.
This was masked by another bug in xg_select, file descriptors where wrongly 
indiocated to be read when they where not.  This made things work in X, but 
not in a terminal.  This bug I fixed in the emacs-23 branch.

I went ahead and added a more general file descriptor handling in process.c, 
where you can add a file descriptor for reading or writing and get a callback 
when I/O is possible.  I then modified dbusbind to use that so writes also are 
asynchronous.  If the recevier wasn't reading and Emacs writes a lot of DBus 
messages, a hang could occur (not that it is very likely, dbus isn't made for 
passing a lot of data around).

So please try this version.

	Jan D.

Re: Reading D-Bus messages

[Ken Brown]

On 9/26/2010 12:31 PM, Jan Djärv wrote:
>
>
> Michael Albinus skrev 2010-09-25 22.54:
>> Jan Djärv<jan.h.d@swipnet.se>   writes:
>>
>>>> If I test it in a non-X11 terminal, arriving D-Bus messages are
>>>> recognised only after pressing a character on the keyboard. So at least
>>>> an additional trigger is missing to handle this event in time.
>>>
>>> This sounds like a bug.  I'll have a look.  Is this the same emacs
>>> binary for X and non-X you are running?
>>
>> Yes.
>>
>>> I don't understand why there is #ifdef subprocess around
>>> add/delete_keyboard_wait_descriptor, but it should not matter.
>>
>> For testing, I use the example in (info "(dbus) Receiving Method Calls")
>> In the non-X test case, you must call dbus-send from another terminal,
>> with the same $DBUS_SESSION_BUS_ADDRESS set.
>>
>
> Ok, I checked in several changes.  There where at least two bugs.
> First dbusbind didn't process all messages, just one.  So things didn't work
> well when DBUS had read more than one message into its queue.
> This was masked by another bug in xg_select, file descriptors where wrongly
> indiocated to be read when they where not.  This made things work in X, but
> not in a terminal.  This bug I fixed in the emacs-23 branch.
>
> I went ahead and added a more general file descriptor handling in process.c,
> where you can add a file descriptor for reading or writing and get a callback
> when I/O is possible.  I then modified dbusbind to use that so writes also are
> asynchronous.  If the recevier wasn't reading and Emacs writes a lot of DBus
> messages, a hang could occur (not that it is very likely, dbus isn't made for
> passing a lot of data around).
>
> So please try this version.

Works for me in Cygwin.  Thanks.

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I went ahead and added a more general file descriptor handling in
> process.c, where you can add a file descriptor for reading or writing
> and get a callback when I/O is possible.  I then modified dbusbind to
> use that so writes also are asynchronous.  If the recevier wasn't
> reading and Emacs writes a lot of DBus messages, a hang could occur
> (not that it is very likely, dbus isn't made for passing a lot of data
> around).
>
> So please try this version.

Thanks a lot, it works for me in both the X and non-X cases.

Just some minor remarks on your changes in dbusbind.c:

* dbus_fd_cb calls only xd_read_queued_messages. Couldn't both functions
  be merged? Or, since we have the file descriptor in the callback,
  shouldn't we call only xd_read_message for that socket?

* We assume that communication is socket base. This must not be true;
  see the comment in
  <http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#gb9b8b4064fe2bc36f89f399f32979398>. If
  xd_find_watch_fd returns -1, we shall raise an error at least.

> 	Jan D.

Best regards, Michael.

Re: Reading D-Bus messages

[Jan Djärv]

Michael Albinus skrev 2010-09-26 20.38:

>
> Thanks a lot, it works for me in both the X and non-X cases.
>
> Just some minor remarks on your changes in dbusbind.c:
>
> * dbus_fd_cb calls only xd_read_queued_messages. Couldn't both functions
>    be merged? Or, since we have the file descriptor in the callback,
>    shouldn't we call only xd_read_message for that socket?

Yes and yes.  I was lazy, I saw that xd_read_queued_messages wasn't static and 
kept it just in case.  I wasn't sure how to get the DbusConnection from a fd 
so I skipped that.  But feel free to make any changes you think appropriate. 
I don't think xd_get_dispatch_status and xd_pending_messages are used for example.

>
> * We assume that communication is socket base. This must not be true;
>    see the comment in
>    <http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#gb9b8b4064fe2bc36f89f399f32979398>. If
>    xd_find_watch_fd returns -1, we shall raise an error at least.

I'm not sure what you mean.  If you look at the code, the functions 
dbus_watch_get_fd,  dbus_watch_get_unix_fd and dbus_watch_get_socket all 
return the same thing, watch->fd.  We don't really assume socket, any fd that 
can be passed to select will do.  In practice on Unix-like systems, we can't 
get -1 (minus dbus-bugs of course).

	Jan D.

Re: Reading D-Bus messages

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> * dbus_fd_cb calls only xd_read_queued_messages. Couldn't both functions
>>    be merged? Or, since we have the file descriptor in the callback,
>>    shouldn't we call only xd_read_message for that socket?
>
> Yes and yes.  I was lazy, I saw that xd_read_queued_messages wasn't
> static and kept it just in case.  I wasn't sure how to get the
> DbusConnection from a fd so I skipped that.  But feel free to make any
> changes you think appropriate. I don't think xd_get_dispatch_status
> and xd_pending_messages are used for example.

I've tried to adapt it as much as possible. I've kept
xd_read_queued_messages in order to be able to catch errors from
xd_read_message.

>> * We assume that communication is socket base. This must not be true;
>>    see the comment in
>>    <http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#gb9b8b4064fe2bc36f89f399f32979398>. If
>>    xd_find_watch_fd returns -1, we shall raise an error at least.
>
> I'm not sure what you mean.  If you look at the code, the functions
> dbus_watch_get_fd,  dbus_watch_get_unix_fd and dbus_watch_get_socket
> all return the same thing, watch->fd.  We don't really assume socket,
> any fd that can be passed to select will do.  In practice on Unix-like
> systems, we can't get -1 (minus dbus-bugs of course).

Yes, you are right. If dbus_watch_get* returns something less than zero,
we silently return as well. This might be sufficient.

> 	Jan D.

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/27/2010 11:37 AM, Michael Albinus wrote:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>>> * dbus_fd_cb calls only xd_read_queued_messages. Couldn't both functions
>>>     be merged? Or, since we have the file descriptor in the callback,
>>>     shouldn't we call only xd_read_message for that socket?
>>
>> Yes and yes.  I was lazy, I saw that xd_read_queued_messages wasn't
>> static and kept it just in case.  I wasn't sure how to get the
>> DbusConnection from a fd so I skipped that.  But feel free to make any
>> changes you think appropriate. I don't think xd_get_dispatch_status
>> and xd_pending_messages are used for example.
>
> I've tried to adapt it as much as possible. I've kept
> xd_read_queued_messages in order to be able to catch errors from
> xd_read_message.
>
>>> * We assume that communication is socket base. This must not be true;
>>>     see the comment in
>>>     <http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#gb9b8b4064fe2bc36f89f399f32979398>. If
>>>     xd_find_watch_fd returns -1, we shall raise an error at least.
>>
>> I'm not sure what you mean.  If you look at the code, the functions
>> dbus_watch_get_fd,  dbus_watch_get_unix_fd and dbus_watch_get_socket
>> all return the same thing, watch->fd.  We don't really assume socket,
>> any fd that can be passed to select will do.  In practice on Unix-like
>> systems, we can't get -1 (minus dbus-bugs of course).
>
> Yes, you are right. If dbus_watch_get* returns something less than zero,
> we silently return as well. This might be sufficient.

To finish off the Cygwin issue that started this thread, dbus now works 
fine in emacs-24 under Cygwin, but not in emacs-23.  Would anyone object 
if I were to apply the following patch to the emacs-23 branch to fix the 
(Cygwin-specific) problem there?

=== modified file 'src/keyboard.c'
--- src/keyboard.c      2010-07-05 17:16:59 +0000
+++ src/keyboard.c      2010-09-27 19:33:05 +0000
@@ -4107,7 +4107,7 @@
          interrupt handlers have not read it, read it now.  */

  /* Note SIGIO has been undef'd if FIONREAD is missing.  */
-#ifdef SIGIO
+#if defined (SIGIO) || defined (CYGWIN)
        gobble_input (0);
  #endif /* SIGIO */
        if (kbd_fetch_ptr != kbd_store_ptr)


If this is OK, I have one more question:  How do I guarantee that the 
patch doesn't propagate to the trunk?  Is it enough to say in the log 
message that it's for emacs-23 only?

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> To finish off the Cygwin issue that started this thread, dbus now
> works fine in emacs-24 under Cygwin, but not in emacs-23.  Would
> anyone object if I were to apply the following patch to the emacs-23
> branch to fix the (Cygwin-specific) problem there?
>
> === modified file 'src/keyboard.c'
> --- src/keyboard.c      2010-07-05 17:16:59 +0000
> +++ src/keyboard.c      2010-09-27 19:33:05 +0000
> @@ -4107,7 +4107,7 @@
>          interrupt handlers have not read it, read it now.  */
>
>  /* Note SIGIO has been undef'd if FIONREAD is missing.  */
> -#ifdef SIGIO
> +#if defined (SIGIO) || defined (CYGWIN)
>        gobble_input (0);
>  #endif /* SIGIO */
>        if (kbd_fetch_ptr != kbd_store_ptr)

Likely it is sufficient to move the call of xd_read_queued_messages out
of gobble_input:

 --8<---------------cut here---------------start------------->8---
*** ~/src/emacs-23/src/keyboard.c.~100064~	2010-09-27 23:18:30.840864838 +0200
--- ~/src/emacs-23/src/keyboard.c	2010-09-27 23:18:01.942112064 +0200
***************
*** 4106,4111 ****
--- 4106,4116 ----
        /* One way or another, wait until input is available; then, if
  	 interrupt handlers have not read it, read it now.  */
  
+ #ifdef HAVE_DBUS
+       /* Read D-Bus messages.  */
+       xd_read_queued_messages ();
+ #endif /* HAVE_DBUS */
+ 
  /* Note SIGIO has been undef'd if FIONREAD is missing.  */
  #ifdef SIGIO
        gobble_input (0);
***************
*** 7051,7061 ****
  gobble_input (expected)
       int expected;
  {
- #ifdef HAVE_DBUS
-   /* Read D-Bus messages.  */
-   xd_read_queued_messages ();
- #endif /* HAVE_DBUS */
- 
  #ifdef SIGIO
    if (interrupt_input)
      {
--- 7056,7061 ----
--8<---------------cut here---------------end--------------->8---

I haven't tested this, 'tho (just being kind of ill).

> If this is OK, I have one more question:  How do I guarantee that the
> patch doesn't propagate to the trunk?  Is it enough to say in the log
> message that it's for emacs-23 only?

I would say yes.

> Ken

Best regards, Michael.

Re: Reading D-Bus messages

[Ken Brown]

On 9/27/2010 5:23 PM, Michael Albinus wrote:
> Ken Brown<kbrown@cornell.edu>  writes:
>
>> To finish off the Cygwin issue that started this thread, dbus now
>> works fine in emacs-24 under Cygwin, but not in emacs-23.  Would
>> anyone object if I were to apply the following patch to the emacs-23
>> branch to fix the (Cygwin-specific) problem there?
>>
>> === modified file 'src/keyboard.c'
>> --- src/keyboard.c      2010-07-05 17:16:59 +0000
>> +++ src/keyboard.c      2010-09-27 19:33:05 +0000
>> @@ -4107,7 +4107,7 @@
>>           interrupt handlers have not read it, read it now.  */
>>
>>   /* Note SIGIO has been undef'd if FIONREAD is missing.  */
>> -#ifdef SIGIO
>> +#if defined (SIGIO) || defined (CYGWIN)
>>         gobble_input (0);
>>   #endif /* SIGIO */
>>         if (kbd_fetch_ptr != kbd_store_ptr)
>
> Likely it is sufficient to move the call of xd_read_queued_messages out
> of gobble_input:
>
>   --8<---------------cut here---------------start------------->8---
> *** ~/src/emacs-23/src/keyboard.c.~100064~	2010-09-27 23:18:30.840864838 +0200
> --- ~/src/emacs-23/src/keyboard.c	2010-09-27 23:18:01.942112064 +0200
> ***************
> *** 4106,4111 ****
> --- 4106,4116 ----
>          /* One way or another, wait until input is available; then, if
>    	 interrupt handlers have not read it, read it now.  */
>
> + #ifdef HAVE_DBUS
> +       /* Read D-Bus messages.  */
> +       xd_read_queued_messages ();
> + #endif /* HAVE_DBUS */
> +
>    /* Note SIGIO has been undef'd if FIONREAD is missing.  */
>    #ifdef SIGIO
>          gobble_input (0);
> ***************
> *** 7051,7061 ****
>    gobble_input (expected)
>         int expected;
>    {
> - #ifdef HAVE_DBUS
> -   /* Read D-Bus messages.  */
> -   xd_read_queued_messages ();
> - #endif /* HAVE_DBUS */
> -
>    #ifdef SIGIO
>      if (interrupt_input)
>        {
> --- 7056,7061 ----
> --8<---------------cut here---------------end--------------->8---

This works for me.  Maybe you should test it too when you get a chance 
and then check it in if you're satisfied.

Ken

Re: Reading D-Bus messages

[Michael Albinus]

Ken Brown <kbrown@cornell.edu> writes:

> This works for me.  Maybe you should test it too when you get a chance
> and then check it in if you're satisfied.

Works for me as well. I've committed it to the emacs-23 branch.

> Ken

Best regards, Michael.