DBusWatch function, DBusTimeout functions Why these functions is needed ?

Sun Jan 8 09:47:21 UTC 2017

Hi Martin, Hi Thiago,

Thank you all from spent your time in explanation for me. It was very
useful for me.
Happy New Year and Merry Christmas !!!!!!!!!!!!

On 28 December 2016 at 22:57, Martin Häfner <martinhaefner at web.de> wrote:

> Hi Denis,
>
> well, you are still too fixated on an evenloop where only dbus is doing
> I/O. Think about an application which is doing lot of stuff at the same
> time. Timers, sockets, UI events, and so on. And just one aspect of this
> app is doing dbus. If dbus was a closed library you would then start a
> separate thread just for the dbus communication. But threads are superfluid
> in this case and only make things much more complex. dbus API let's you
> integrate the dbus sockets and timers to your event loop (and does not
> compel you to use a certain implementation). So, dbus tells you "I have a
> socket, you may call poll, epoll, select or whatever and then call me back
> if something happened on the socket, so I will read out the data and make a
> message call from it".
>
> dbus_connection_send will enqueue a new message which can be sent when the
> socket tells you that it is ready to send - which is probably nearly always
> the case. dbus_connection_flush indeed breaks your event loop approach
> since this call will block doing a select just on the dbus socket, so all
> other events are blocked in this case. You probably never should use this
> in a eventloop driven dbus application.
>
> dbus API also supports blocking method calls which also start internal
> select loops in order to wait for a timeout or a message return, so this is
> also not favourable in an eventloop driven application. You can think of
> these functions beeing used in simple batch tools.
>
> Regards,
> Martin
>
>
> 2016-12-28 10:21 GMT+01:00 Денис Котов <redradist at gmail.com>:
>
>> 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.
>>
>> One additional point:
>> "*When you use dbus_connection_send()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gae1cb64f4cf550949b23fd3a756b2f7d0> or
>> one of its variants to send a message, the message is added to the outgoing
>> queue. It's actually written to the network later; either
>> in dbus_watch_handle()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusWatch.html#gac2acdb1794450ac01a43ec4c3e07ebf7> invoked
>> by your main loop, or in dbus_connection_flush()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e68d9d2f41d655a4151ddeb807ff54> which
>> blocks until it can write out the entire outgoing queue. The GLib/Qt add-on
>> libraries again handle the details here for you by setting up watch
>> functions.*"
>>
>> For this I implemented calling *dbus_connection_flush()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e68d9d2f41d655a4151ddeb807ff54> *on
>> event *POLLOUT*, but this event never appears. For me it is very strange
>> ...
>> But all sent messages by  dbus_connection_send()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gae1cb64f4cf550949b23fd3a756b2f7d0>
>>  arrives *successfully* (it even I have not received *POLLOUT *for
>> making flush).
>>
>> Do you know who ca *dbus_connection_flush()
>> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e68d9d2f41d655a4151ddeb807ff54> *in
>> this case ?
>>
>> On 27 December 2016 at 21:02, Martin Häfner <martinhaefner at web.de> wrote:
>>
>>> Hi Denis,
>>>
>>> the functions are called within this block in the dispatcher.cpp in
>>> order to register your callbacks:
>>>
>>> Private(DBusConnection* conn)
>>> {
>>> #ifdef USE_POLL
>>>    dbus_connection_set_watch_functions(conn, &add_watch, &remove_watch,
>>> &toggle_watch, this, nullptr);
>>>    dbus_connection_set_timeout_functions (conn, &add_timeout,
>>> &remove_timeout, &toggle_timeout, this, nullptr);
>>> #endif
>>> }
>>>
>>> They are just called once. Sockets must be monitored in order to let
>>> dbus know when a new message arrives. But dbus also has timeout handling -
>>> if messages do not arrive intime or the daemon is not able to send data on
>>> the socket in a certain time. This is why timeouts are needed. Note that in
>>> a simple dbus application there is mostly only one socket alive at a time
>>> (the bus connection).
>>>
>>> Regards,
>>> Martin
>>>
>>> 2016-12-26 10:59 GMT+01:00 Денис Котов <redradist at gmail.com>:
>>>
>>>> Hi Martin,
>>>>
>>>> Thanks for link, but I have not found where you use the
>>>> following functions:
>>>> dbus_connection_set_watch_functions
>>>> dbus_connection_set_timeout_functions
>>>>
>>>> ???
>>>>
>>>> From your explanation and this example https://lists.freedesk
>>>> top.org/archives/dbus/2007-October/008859.html I have understood that watch
>>>> - is a file descriptor that needed to be monitored ( for example in a new
>>>> client has connected to service ), but timeout what is the purpose of this
>>>> variable ?
>>>> Okay, let's imagine that libdbus asked to create the timer, but for
>>>> what purposes ? Should I handle file descriptor in that time or what ? And
>>>> if I would not handle something in that timeout what will happen ?
>>>>
>>>> On 25 December 2016 at 22:10, Martin Häfner <martinhaefner at web.de>
>>>> wrote:
>>>>
>>>>> Hi Denis,
>>>>>
>>>>> DBusWatch and Timeout are dbus callouts to integrate the dbus library
>>>>> into external event loops. You can write simple dbus driven applications
>>>>> with a simple main loop just calling the dbus_connection_read_write_dispatch
>>>>> function in a simple main loop. If you develop real world applications
>>>>> you will probably have to integrate the dbus API into a third-party main
>>>>> loop, e.g. from QApplication when implementing a Qt base GUI application.
>>>>> For the Qt example, you will probably make a mapping from a DBusTimeout to
>>>>> a QTimer and from a DBusWatch to QSocketNotifier. So, whenever DBus tells
>>>>> you to create a watch you will create a QSocketNotifier, and whenever DBus
>>>>> calls the callout to create a Timeout you create a QTimer. I have written a
>>>>> template-based C++ wrapper on top of DBus which implements the two
>>>>> different possibilities, once in a simple poll loop: You can have a look
>>>>> into the example at https://github.com/martinhaefn
>>>>> er/simppl/blob/dbus2/src/dispatcher.cpp
>>>>>
>>>>> Regards,
>>>>> Martin
>>>>>
>>>>> 2016-12-24 19:02 GMT+01:00 Денис Котов <redradist at gmail.com>:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Currently I have faced with understanding of watch and timeout
>>>>>> functions in libdbus.
>>>>>> I do not quit understand why they are needed.
>>>>>>
>>>>>> From description I understand they are needed to check state of
>>>>>> socket. If something changes then from libdbus I will receive this message
>>>>>> and I have either to read something or to write something to socket.
>>>>>>
>>>>>> It means that I should not create infinite while loop, but register
>>>>>> callbacks and when will be possibility I will write to out-queue or read to
>>>>>> in-queue, am I right ?
>>>>>>
>>>>>> And maybe some brief explanation what is DBusTimeout function ?
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Best RegardsDenis Kotov*
>>>>>>
>>>>>> _______________________________________________
>>>>>> dbus mailing list
>>>>>> dbus at lists.freedesktop.org
>>>>>> https://lists.freedesktop.org/mailman/listinfo/dbus
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Best RegardsDenis Kotov*
>>>>
>>>
>>>
>>
>>
>> --
>>
>> *Best RegardsDenis Kotov*
>>
>
>

-- 

*Best RegardsDenis Kotov*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20170108/88133287/attachment.html>