GNOME Bugzilla – Bug 645525
CPU load and grilo requests
Last modified: 2018-09-24 09:16:17 UTC
When running an application rendering a UI at a fixed frame rate (like 60fps), you might end up always having something to do in the main loop at all time. In that case you will see the requests you make through the grilo API block forever. This is due to the usage of g_idle_add*() functions in the core. This might be worked around by replacing all g_idle_add* calls by g_timeout_add(0, ...), so we ensure to return to the caller as soon as possible, but we also ensure that the plugin's callback will be called at some point (and not delayed forever). Another way to do that would be to run all plugins in another thread (only 1 thread for all plugins) separated from the caller's thread. The grilo API would then just be a kind of proxy to internal sources callbacks.
Reposting a comment on Iago's behalf (comment was lost due a failure in BGO machine) "Mmm... if the queries are blocked forever is because you are doing a lot of work in the idle loop all the time. If we force the grilo stuff to kick in that stuff will block for some time as well, and depending on what you are doing that may be what you want or not, so I am not sure if this work around is a good idea. For this purpose there are priorities in the idle operations, so I think we should try use them instead. At least on the grilo side I think we are queuing the idle calls with default priority, so maybe you can lower the priority of you idle loop operations or we could provide a means to set the priority for the grilo calls: the GrlOptions API we are defining now in the mailing list could be used to introduce this possibility btw."
Working on it
Created attachment 185183 [details] [review] Use higher priorities for non-idle relays This patch makes to use higher priorities when GRL_RESOLVE_IDLE_RELAY flag is not used. Lionel already tested this patch and works fine for him.
(In reply to comment #3) > Created an attachment (id=185183) [details] [review] > Use higher priorities for non-idle relays Actually, this patch does not affect the relays (these are used to return the results), this patch acts on the operation starters only: the result emission would not be affected by this and operation results should still be blocked forever under heavy use of the main loop by the UI. > This patch makes to use higher priorities when GRL_RESOLVE_IDLE_RELAY flag is > not used. This is not a proper fix, it is just a workaround to the real problem. > Lionel already tested this patch and works fine for him. I understand how this patch can help to avoid operations blocking before actually being started, however I fail to see how this prevents the same problem from happening when it is time to hand the results over to the client. That's why I think, as I mentioned above, that a proper fix would require to let the user set the priorities to use for each operation and use them in all idle operations (both the starters and the relays), and maybe even provide our own idle setup mechanism for plugin developers to use (to make sure these use the priorities suggested by the client).
(In reply to comment #4) > That's why I think, as I mentioned above, that a proper fix would require to > let the user set the priorities to use for each operation and use them in all > idle operations (both the starters and the relays), and maybe even provide our > own idle setup mechanism for plugin developers to use (to make sure these use > the priorities suggested by the client). Yes, the idea is to use the (future) options/caps feature to allow user to specify their own priority.
Issues Iago told still apply, but as it seems to help reporter in his problem, I've pushed it as commit 1b5c6c253d708ce73371c6c5267d26e2f13782f3 Author: Juan A. Suarez Romero <jasuarez@igalia.com> Date: Thu Mar 31 11:42:46 2011 +0000 core: Use higher priorities when dealing with no IDLE_RELAY flag When user do not use the GRL_RESOLVE_IDLE_RELAY, usually means he needs the results as soon as possible. As we relay on g_idle_add() to do our internal work, we should handle this i functions with higher priority in this case. This patch makes to use G_PRIORITY_DEFAULT_IDLE when user requests the GRL_RESOLVE_IDLE_RELAY, while G_PRIORITY_HIGH_IDLE is used when the flag is set up. This fixes https://bugzilla.gnome.org/show_bug.cgi?id=645525 Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> src/grl-media-source.c | 27 ++++++++++++++++++++++----- src/grl-metadata-source.c | 12 ++++++++++-- 2 files changed, 32 insertions(+), 7 deletions(-)
Review of attachment 185183 [details] [review]: Already committed
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/grilo/issues/15.