GNOME Bugzilla – Bug 314491
intelligent I/O thread management
Last modified: 2008-09-06 18:54:44 UTC
As I recall - one thing that needs fixing in gnome-vfs is intelligent job queuing. AFAIR there is 1-big-queue - and everything gets shoved on it & processed in (prioritised?) order. Unfortunately this means if nautilus has 1 window browsing /share/dead-nfs-mount and 1 window browsing /home/$USER - then the deadly badness eventually clobbers all the worker threads which sit there hanging NFS-wise. Or - conversely - if we're viewing ssh://deadly-slow-machine/ - this will similarly clog the thread pool & slow parallel local accesses. Anyhow - it would -seem- to be a good idea to have a more intelligent job allocation system, that ensures that no more than <N>% of the thread pool can be working at a given sub-path. ie. you can block 1/2 the threads but the other 1/2 are still free to do other work. Of course symlinks can break even the best plans - but at least this would catch a large number of the most trivial cases & drastically improve I/O in the most common bad cases. Or have I missed something ? :-)
gicmo committed a patch that ported GnomeVFS to GThreadPool. However, I still couldn't find any implementation of the thread sanity algorithm you propose. Updating version.
*** Bug 74371 has been marked as a duplicate of this bug. ***
gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22, hence mass-closing many of the gnome-vfs requests/bug reports. This means that gnome-vfs is NOT actively maintained anymore, however patches are still welcome. If your reported issue is still valid for gio/gvfs, please feel free to file a bug report against glib/gio or gvfs. @Bugzilla mail recipients: query for gnome-vfs-mass-close to get rid of this notification noise all together. General further information: http://en.wikipedia.org/wiki/GVFS Reasons behind this decision are listed at http://www.mail-archive.com/gnome-vfs-list@gnome.org/msg00899.html