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

[dibo20 at wp.pl]

W dniu 13.01.2011 21:12, Henry Vermaak pisze:
> On 13 January 2011 19:51,<dibo20 at wp.pl>  wrote:
>> 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.
> Indeed, it's pretty ugly.
>
>> 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?
> I changed your code to run in a thread and it works well for me.  I
> made a thread safe TQueue derivative that I add messages to, then I
> notify the gui thread with PostMessage.  The gui thread pops the
> messages from the queue and displays them.  This works even if I add
> huge delays in the gui thread, since the queue is a buffer.  This
> solution should also work with other widgetsets.
>
> I'll send you some code tomorrow (it's on my work computer).
>
> Henry
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Ok, I found reason by analyzing your demo. My threads were not different 
from yours (except PostMessage - I am using Synchronize). I could not 
find the place where you call Sleep to reduce CPU usage by thread loop. 
Then I found this line:
dbus_connection_read_write(conn, 100);
And this is solution. I used 0 timeout (involuntarily, I just copy and 
paste from console demo). It seems that for the console version is 
sufficient time, but not enough for GUI application listening in 
threads. So I can use this timeout to reduce CPU usage instead of 
standard Sleep(100). Additionally, thistimeout catch all "lost" signals. 
So now I get 100% of sent signals. After this modification, my programs 
based on threads started working again.
Of course, problem with "dbus_connection_set_wakeup_main_function" and 
"dbus_connection_set_watch_functions" still exists. But now when threads 
working again, I can live with that. If you don't have what you like, 
then you like what you have ;)

Thank you all for your invaluable help.
Regards. Dibo.