This message was posted on behalf of Intel Corporation
I do see an increase of the CPU consumed by gatttool however it does not reach 70-80%. Nevertheless, have you tried to change the niceness of the process, that should give it less priority therefore it should consume less CPU. Check http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/ to learn how to change the niceness level of a process.
Thanks for your reply.
It starts at 30-40% and then rises to 70% or above and stays there. In any case, this seems like a bug because even while normal scanning(before connection and disconnection), while being connected the tool hardly takes 1%. It seems the cleanup code in disconnect_io function causes issues. I will try the niceness feature.
1 of 1 people found this helpful
I guess I found what is wrong. Gatttool uses glib main event loop and so io channels are attached as sources to the default main context (read glib docs for more clarification). As an example in 'bluez/attrib/interactive.c' in function cmd_connect 'g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL)' is done. This function will return a gsource which has to be removed from watch once io channel is lost or deleted. In absence of this, glib will keep waiting on this io channel (fd) and cause EINVAL as return code. (My knowledge is patchy but I guess that's what happens). So when disconnecting the device this watch needs to be removed.
I do it in following way - define a new global - guint gsrc.
Change the line in cmd_connect to
gsrc = g_io_add_watch(iochannel, G_IO_HUP, channel_watcher, NULL);
After disconnection, in disconnect_io function at the end I do g_source_remove(gsrc);
This fixes gatttool cpu usage bug in interactive mode.
I did ask on IRC but I didn't get any replies.