DBusWatch function, DBusTimeout functions Why these functions is needed ?

Thiago Macieira thiago at kde.org
Wed Dec 28 12:31:17 UTC 2016


Em quarta-feira, 28 de dezembro de 2016, às 11:21:29 BRST, Денис Котов 
escreveu:
> Hi Martin,
> 
> *>> They are just called once. Sockets must be monitored in order to let
> dbus know when a new message arrives.*
> I am only curios why *DBus *cannot monitor socket by itself. First time
> when I faced with it it was surprise for me.

*How* would it do that? You're in control of your application when the library 
isn't processing messages. You have to tell the library when there are new 
messages or when enough time has passed. 

libdbus does not start threads. That's not in its design: it's designed to 
work even with non-threaded applications and systems. Other implementations 
like GDBus do use threads so that you keep getting new messages even when your 
application is doing something else. But that's a headache of itself: I 
changed QtDBus to use threads in 5.6 and we're still finding race conditions 
and OS shortcomings.

One of Windows's shortcomings is unfixable.

> For this I implemented calling *dbus_connection_flush()
> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e6
> 8d9d2f41d655a4151ddeb807ff54> *on
> event *POLLOUT*, but this event never appears. For me it is very strange

POLLOUT is only required when the kernel-side SendQ buffers are full. That is 
to say, you have to write more data and faster than the receiver can handle 
them. Since dbus-daemon isn't very complex, it's probably handling them quite 
fast.

> Do you know who ca *dbus_connection_flush()
> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e6
> 8d9d2f41d655a4151ddeb807ff54> *in
> this case ?

Undecipherable. Can you rephrase?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



More information about the dbus mailing list