dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de>
2009-07-17 19:30:02 GMT

Zajcev Evgeny <lg.zevlg <at> gmail.com> writes:
> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:
>>
>>> I wouldn't call our dbus support an API yet. It is the product of 1 hour
>>> of work with a very specific goal, getting empathy to work. We haven't
>>> considered anything yet, let alone thought about a possible collaboration.
>>> Consider our dbus support a design study, more or less a proof that our
>>> FFI concept is flexible enough to furtherly support it.
>>
>> I see. I do not understand whether you support also receiving signals
>> and method calls. This would require a kind of mainloop integration; is
>> this possible with FFI?
>
> yes, we have an ability to integrate glib's event loop into SXEmacs,
> thats how i've got sxempathy to work. This integration not yet in
> ffi-dbus AFAIR
Porting dbusbind.c to dbusbind.el has progressed last weeks. Arguments
marshalling / unmarshallings works for arbitrary D-Bus types, I can call
D-Bus methods and show the result, I can subscribe to signals, read
them, and see them as misc-user events.
What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
speaking about dbus-glib , that is not used. There is a Lisp function
(xd-read-queued-messages) which checks the system and session buses for
new incoming messages, reads them, and transforms them into a misc-user
event. This function must be called regularly in the SXEmacs main

Re: dbusbind.el

Steve Youngs <steve <at> sxemacs.org>
2009-07-18 06:01:52 GMT

* Michael Albinus <michael.albinus <at> gmx.de> writes:
> Porting dbusbind.c to dbusbind.el has progressed last weeks. Arguments
> marshalling / unmarshallings works for arbitrary D-Bus types, I can call
> D-Bus methods and show the result, I can subscribe to signals, read
> them, and see them as misc-user events.
Excellent!
> What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
> speaking about dbus-glib , that is not used. There is a Lisp function
> (xd-read-queued-messages) which checks the system and session buses for
> new incoming messages, reads them, and transforms them into a misc-user
> event. This function must be called regularly in the SXEmacs main
> loop. How do I get this?
<caveat>
What I know about D-Bus could be written on the back of a postage
stamp (verbosely)
</caveat>
Why does #'xd-read-queued-messages need to be called in the SXEmacs
mainloop? Is it so there is less chance of if getting blocked,
interrupted, or missed? Maybe we could plonk it on its own "worker"
thread like we can do with audio playback (SXEmacs can play audio
asynchronously).
--
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |

Re: dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de>
2009-07-18 08:41:57 GMT

Steve Youngs <steve <at> sxemacs.org> writes:
> > What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
> > speaking about dbus-glib , that is not used. There is a Lisp function
> > (xd-read-queued-messages) which checks the system and session buses for
> > new incoming messages, reads them, and transforms them into a misc-user
> > event. This function must be called regularly in the SXEmacs main
> > loop. How do I get this?
>
> <caveat>
> What I know about D-Bus could be written on the back of a postage
> stamp (verbosely)
> </caveat>
I've started with even less knowledge, 2 years ago.
> Why does #'xd-read-queued-messages need to be called in the SXEmacs
> mainloop? Is it so there is less chance of if getting blocked,
> interrupted, or missed? Maybe we could plonk it on its own "worker"
> thread like we can do with audio playback (SXEmacs can play audio
> asynchronously).
No special need for the mainloop. It simply must be called in "real
time" (whatever this means), in order to check for pending incoming
D-Bus messages.
Best regards, Michael.

Re: dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de> writes:
> Steve Youngs <steve <at> sxemacs.org> writes:
>
>> > What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
>> > speaking about dbus-glib , that is not used. There is a Lisp function
>> > (xd-read-queued-messages) which checks the system and session buses for
>> > new incoming messages, reads them, and transforms them into a misc-user
>> > event. This function must be called regularly in the SXEmacs main
>> > loop. How do I get this?
>>
>> <caveat>
>> What I know about D-Bus could be written on the back of a postage
>> stamp (verbosely)
>> </caveat>
>
> I've started with even less knowledge, 2 years ago.
>
>> Why does #'xd-read-queued-messages need to be called in the SXEmacs
>> mainloop? Is it so there is less chance of if getting blocked,
>> interrupted, or missed? Maybe we could plonk it on its own "worker"
>> thread like we can do with audio playback (SXEmacs can play audio
>> asynchronously).
>
> No special need for the mainloop. It simply must be called in "real
> time" (whatever this means), in order to check for pending incoming
> D-Bus messages.
How frequent do you need this to be called? And what's the additional
load when 1. there are no events and 2. there are events? The usual way

Re: dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de>
2009-07-18 22:32:36 GMT

Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:
>> No special need for the mainloop. It simply must be called in "real
>> time" (whatever this means), in order to check for pending incoming
>> D-Bus messages.
>
> How frequent do you need this to be called? And what's the additional
> load when 1. there are no events and 2. there are events? The usual way
> for lisp code to get invoked regularly is itimers, is that an option?
Frequency: it depends, how reactive SXEmacs shall be. Signals come in
asynchronously; you can call methods asynchronously and want to see the
result when available, and alike.
It would be good to poll the message queue every (x) tenth of a
second. One second shall be the absolute maximum between two checks (but
likely, this is too long).
I have no figures about additional load. There are at least two calls of
dbus_connection_read_write() and dbus_connection_pop_message() per bus
(system bus and session bus). If there are incoming messages, they must
be decoded; load depends on parameters. And an associated handler, a
Lisp function, can be called - everybody can register.
What I can say is that nobody has ever claimed too heavy load in GNU
Emacs because of this - the code has been added back in December 2007.
itimers might be an option, I'll give them a try.
> Sebastian

Re: dbusbind.el

Steve Youngs <steve <at> sxemacs.org>
2009-07-19 01:18:22 GMT

* Michael Albinus <michael.albinus <at> gmx.de> writes:
> Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:
>>> No special need for the mainloop. It simply must be called in
>>> "real time" (whatever this means), in order to check for pending
>>> incoming D-Bus messages.
>>
>> How frequent do you need this to be called? And what's the
>> additional load when 1. there are no events and 2. there are
>> events? The usual way for lisp code to get invoked regularly is
>> itimers, is that an option?
> Frequency: it depends, how reactive SXEmacs shall be. Signals come
> in asynchronously; you can call methods asynchronously and want to
> see the result when available, and alike.
> It would be good to poll the message queue every (x) tenth of a
> second. One second shall be the absolute maximum between two checks
> (but likely, this is too long).
Floats can be used for itimer values so firing this every 0.1s is
feasible.
> What I can say is that nobody has ever claimed too heavy load in GNU
> Emacs because of this - the code has been added back in December
> 2007.
Good.
> itimers might be an option, I'll give them a try.

Re: dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de>
2009-07-19 07:58:38 GMT

Steve Youngs <steve <at> sxemacs.org> writes:
> > It would be good to poll the message queue every (x) tenth of a
> > second. One second shall be the absolute maximum between two checks
> > (but likely, this is too long).
>
> Floats can be used for itimer values so firing this every 0.1s is
> feasible.
I've added
(unless (get-itimer "dbusbind")
(start-itimer "dbusbind" 'xd-read-queued-messages 0.1 0.1))
That works perfectly. I'll watch it next days, how it behaves under
pressure.
> Is D-Bus something we could treat like a network process? I'm thinking
> #'open-network-stream, and #'open-network-server-stream.
Yes, one could implement the low-level protocol. But libdbus, used via
ffi, is much more convenient.
Best regards, Michael.

Re: dbusbind.el

Steve Youngs <steve <at> sxemacs.org>
2009-07-19 08:42:18 GMT

* Michael Albinus <michael.albinus <at> gmx.de> writes:
> Steve Youngs <steve <at> sxemacs.org> writes:
>> > It would be good to poll the message queue every (x) tenth of a
>> > second. One second shall be the absolute maximum between two checks
>> > (but likely, this is too long).
>>
>> Floats can be used for itimer values so firing this every 0.1s is
>> feasible.
> I've added
> (unless (get-itimer "dbusbind")
> (start-itimer "dbusbind" 'xd-read-queued-messages 0.1 0.1))
> That works perfectly. I'll watch it next days, how it behaves under
> pressure.
OK, looking forward to hearing how it goes.
>> Is D-Bus something we could treat like a network process? I'm thinking
>> #'open-network-stream, and #'open-network-server-stream.
> Yes, one could implement the low-level protocol. But libdbus, used via
> ffi, is much more convenient.
OK, cool.
--
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|