GNOME Bugzilla – Bug 587090
g_file_enumerator_next_files_async() API is bad
Last modified: 2018-05-24 11:54:03 UTC
The function call g_file_enumerator_next_files_async() has a "num_files" argument. This argument is kind of bogus, as I cannot imagine a good use case for enumerating a specific number of files from a directory. What I can imagine, and what is also my use case, is enumerating all files in a directory and when this takes too much time, get progress updates (the g_file_copy() function has something like this). I have no idea what number I am supposed to pass to this function (and apparently, the same goes for everybody else, as everyone just passes 100 for no reason whatsoever). I could have imagined a "milliseconds" argument instead of the "num_files" argument to be the maximum time after which an incomplete list should be returned.
Another thing is that my current approach to solve this problem works like this (pseudocode): freeze_model (model); g_file_enumerator_next_files_async (enumerator, 100, SOME_PRIORITY, add_files_and_query_more, model); g_idle_add_full (SOME_PRIORITY+1, unfreeze_model, model); add_files_and_query_more() does add the files to the model and next_files_async() the next 100. The idea is that the model is only unfrozen when the async function takes too long or all files have been added - which is why the unfreeze_model() is added with a lower priority, so it only gets called when add_files_and_query_more() can not be called. For local files, this does not work, neither in the threaded nor in the non-threaded case. In the non-threaded case, the idle function that queries more files has a higher priority than the unfreezing function, so the unfreezing function is only called after all files have been added. In the threaded case, g_file_enumerator_next_files_async() spawns a thread that needs to fill 100 GFileInfo structs. This takes longer than the main loop needs to see that the async call isn't finished yet and instead calls unfreeze_model(). Every time. So depending on if threading is enabled you get different, but always wrong behavior. I'm working around this problem at the moment by using g_timeout_add(50) instead of g_idle_add() for the unfreeze call, as that is usually enough time to get 100 files stated, and that works around the problem when threads are enabled.
-- 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/glib/issues/228.