[fpc-pascal] D-Bus. Non blocking listening for signals

[dibo20 at wp.pl]

W dniu 13.01.2011 16:02, Henry Vermaak pisze:
> On 13/01/11 15:00, Henry Vermaak wrote:
>> On 13/01/11 12:24, dibo20 at wp.pl wrote:
>>>
>>> "integrate the GLib event loop with an external event loop" - I think
>>> this is what I want.
>>
>> What you want to do is to integrate the dbus connection into your main
>> loop (in this case glib). Let me quote from the documentation:
>>
>> "If you're using GLib or Qt add-on libraries for D-Bus, there are
>> special convenience APIs in those libraries that hide all the details of
>> dispatch and watch/timeout monitoring. For example,
>> dbus_connection_setup_with_g_main().
>>
>> "If you aren't using these add-on libraries, but want to process
>> messages asynchronously, you must manually call
>> dbus_connection_set_dispatch_status_function(),
>> dbus_connection_set_watch_functions(),
>> dbus_connection_set_timeout_functions() providing appropriate functions
>> to integrate the connection with your application's main loop. This can
>> be tricky to get right; main loops are not simple."
>>
>> If you look at the dbus_connection_set_watch_functions documentation:
>>
>> http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gaebf031eb444b4f847606aa27daa3d8e6 
>>
>>
>>
>> You'll see that this will provide you will file descriptors that you can
>> add to your main loop to watch for the dbus events.
>>
>> This is all _much_ simpler if you use the dbus-glib functions:
>>
>> http://www.ibm.com/developerworks/linux/library/l-dbus.html
>>
>> It doesn't look like that header has been translated to pascal, yet.
>> That doesn't matter, since it's now considered obsolete, since glib has
>> dbus support now:
>>
>> http://www.freedesktop.org/wiki/Software/DBusBindings
>>
>> fpc doesn't seem to have bindings for that, either...
>
> Having said all of this, you can get around this by calling blocking 
> dbus calls in a thread and notifying the user interface by virtue of 
> Synchronize, PostMessage and QueueAsycCall.
>
> Henry
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
I'm trying with "dbus_connection_set_watch_functions" but this is not 
easy like it look. I thought that I must only register my event 
procedures by calling this functions but there is much more work. I have 
a headache. Now I understand why dbus documentation begins with the 
words "If you use this low-level API directly, you're signing up for 
some pain" ;) . Tomorrow I look for some "live example" of using this 
functions in C.

I tried with thread. It doesn't catch all signals even if I call 
sleep(1) in loop. I don't know what is reason of this loss. Thread and 
AddEventHandler have this same problem - they don't catch all signals. 
Only one way which works is "g_main_context_set_poll_func" but now I see 
that the application consumes 30% CPU. So now I understand why it catch 
all signals. @**Matthias how you solved problem with CPU and this function?

This all problems started after this upgrade (probably):
http://bugs.freepascal.org/view.php?id=14086
Because before I listened for signals in thread with sleep(100) without 
problems.

P.S. People who have demo from me, please comment line:
dbus_connection_close(conn);
in my_client_app -> busexample.pas
This should not be there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20110113/973e4ffc/attachment.html>