GNOME Bugzilla – Bug 762496
Use a more idiomatic GIO-like API
Last modified: 2018-09-24 09:41:41 UTC
It would be nice if Grilo's asynchronous functions had a idiomatic GIO-like pattern with GCancellables, GAsyncReadyCallbacks, etc.. More importantly, the synchronous functions are not usable from inside a threaded path because they get stuck and never return. As far as I can tell, this is due to not using a thread default GMainContext. Again, something that is typical in GIO-land, when a synchronous method is implemented in terms of its asynchronous counterpart. It can be worked around by using the async variant and wrapping it around a thread default GMainContext and running a GMainLoop.
(In reply to Debarshi Ray from comment #0) > It would be nice if Grilo's asynchronous functions had a idiomatic GIO-like > pattern with GCancellables, GAsyncReadyCallbacks, etc.. > > More importantly, the synchronous functions are not usable from inside a > threaded path because they get stuck and never return. As far as I can tell, > this is due to not using a thread default GMainContext. Again, something > that is typical in GIO-land, when a synchronous method is implemented in > terms of its asynchronous counterpart. This is a plain bug, test case would be useful. I'm guessing it's a problem with the async machinery that doesn't check for whether the dispatch is done from the right thread. Please file a separate bug with a test case and we can look into it. > It can be worked around by using the async variant and wrapping it around a > thread default GMainContext and running a GMainLoop. The reason it's done that way is because we want to batch results, otherwise you hog the main loop preparing results, and dispatching them one-by-one. GIO-like API should be possible rather easily for functions that only return a single result, but the API changes for the browse and search functions would be pretty big, with the problems mentioned above.
(In reply to Bastien Nocera from comment #1) > The reason it's done that way is because we want to batch results, otherwise > you hog the main loop preparing results, and dispatching them one-by-one. > Couldn't the source do it in a separate task and then use notify results are ready to be dispatched, and use GIO-alike API to get them?
(In reply to Juan A. Suarez Romero from comment #2) > (In reply to Bastien Nocera from comment #1) > > > The reason it's done that way is because we want to batch results, otherwise > > you hog the main loop preparing results, and dispatching them one-by-one. > > > > Couldn't the source do it in a separate task and then use notify results are > ready to be dispatched, and use GIO-alike API to get them? Sure it could, but we'd need to know what the new API would look like before committing to writing any code.
(In reply to Bastien Nocera from comment #3) > (In reply to Juan A. Suarez Romero from comment #2) > > (In reply to Bastien Nocera from comment #1) > > > > > The reason it's done that way is because we want to batch results, otherwise > > > you hog the main loop preparing results, and dispatching them one-by-one. > > > > > > > Couldn't the source do it in a separate task and then use notify results are > > ready to be dispatched, and use GIO-alike API to get them? > > Sure it could, but we'd need to know what the new API would look like before > committing to writing any code. There is prior art in the GNOME platform for this (as I might have mentioned a few times elsewhere, but I might misremember). There is g_file_copy and g_file_copy_async/finish [1]. It uses the 'progress_callback' to notify the caller as chunks of bytes are copied from source to destination. Then there is libgdata, which is a bit more elaborate. For example, to get all the entries from your Google Drive, you'd first create a batched GDataDocumentsQuery with gdata_documents_query_new_with_limits [2]. This acts, sort of, like a cursor. Then, you'd use gdata_documents_service_query_documents [3] to get a batched GDataDocumentsFeed. Once you are done reading this feed, gdata_query_next_page [4] will move your existing GDataDocumentsQuery instance to the next page. Repeat the steps to get your next batch. This is what gvfs and gnome-online-miners use to access Drive content. [1] https://developer.gnome.org/gio/stable/GFile.html#g-file-copy [2] https://developer.gnome.org/gdata/unstable/GDataDocumentsQuery.html#gdata-documents-query-new-with-limits [3] https://developer.gnome.org/gdata/unstable/GDataDocumentsService.html#gdata-documents-service-query-documents [4] https://developer.gnome.org/gdata/unstable/GDataQuery.html#gdata-query-next-page
(In reply to Debarshi Ray from comment #4) > There is g_file_copy and g_file_copy_async/finish [1]. It uses the > 'progress_callback' to notify the caller as chunks of bytes are copied from > source to destination. Note that the way things stand at the moment, g_file_copy_async is not introspectable due to the progress_callback. See bug 746111
(In reply to Bastien Nocera from comment #1) > (In reply to Debarshi Ray from comment #0) > > More importantly, the synchronous functions are not usable from inside a > > threaded path because they get stuck and never return. As far as I can tell, > > this is due to not using a thread default GMainContext. Again, something > > that is typical in GIO-land, when a synchronous method is implemented in > > terms of its asynchronous counterpart. > > This is a plain bug, test case would be useful. I'm guessing it's a problem > with the async machinery that doesn't check for whether the dispatch is done > from the right thread. > > Please file a separate bug with a test case and we can look into it. This is quite obvious if you grep for 'grl_' in gnome-photos or gnome-online-miners. You'll see how it is worked around. It's quite easy to reproduce the problem if you replace the sync-implemented-by-async-wrapped-by-thread-default-context workarounds with the sync variants of the Grilo API. But, sure, I will arrange a test case and file a separate bug.
(In reply to Bastien Nocera from comment #1) > (In reply to Debarshi Ray from comment #0) > > It would be nice if Grilo's asynchronous functions had a idiomatic GIO-like > > pattern with GCancellables, GAsyncReadyCallbacks, etc.. > > > > More importantly, the synchronous functions are not usable from inside a > > threaded path because they get stuck and never return. As far as I can tell, > > this is due to not using a thread default GMainContext. Again, something > > that is typical in GIO-land, when a synchronous method is implemented in > > terms of its asynchronous counterpart. > > This is a plain bug, test case would be useful. I'm guessing it's a problem > with the async machinery that doesn't check for whether the dispatch is done > from the right thread. > > Please file a separate bug with a test case and we can look into it. Filed bug 787312. Although I must say that the problem should have been obvious to anybody with a basic understanding of sync/async variants work in GIO.
-- 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/81.