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