W dniu 13.01.2011 21:12, Henry Vermaak pisze:
On 13 January 2011 19:51,<dib...@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@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
