Re: DBusWatch function, DBusTimeout functions Why these functions is needed ?

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-S0/[email protected]> 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 Денис Котов <[email protected]>:
>
>> 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-S0/[email protected]> 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 Денис Котов <[email protected]>:
>>>
>>>> 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-S0/[email protected]>
>>>> 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 Денис Котов <[email protected]>:
>>>>>
>>>>>> 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
>>>>>> [email protected]
>>>>>> https://lists.freedesktop.org/mailman/listinfo/dbus
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Best RegardsDenis Kotov*
>>>>
>>>
>>>
>>
>>
>> --
>>
>> *Best RegardsDenis Kotov*
>>
>
>


-- 

*Best RegardsDenis Kotov*

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus