After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 44572 - cancelling an async. gnome-vfs call won't interrupt I/O
cancelling an async. gnome-vfs call won't interrupt I/O
Status: RESOLVED WONTFIX
Product: gnome-vfs
Classification: Deprecated
Component: Async operations
0.1
Other Linux
: Normal normal
: later
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Blocks:
 
 
Reported: 2000-11-06 21:18 UTC by Darin Adler
Modified: 2008-09-06 18:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Darin Adler 2001-09-10 00:45:25 UTC
The current design only checks for cancellation after a piece of I/O is
complete. So if the I/O blocks for a long time, there's no provision for
cancelling it. This means that even if they want to, modules can't do a good job
of implementing cancel.

In particular, if you hang doing name lookup in the HTTP module, then do a
cancel, that thread will be around forever. This is bad because it's a thread
leak I think.



------- Additional Comments From darin@bentspoon.com 2000-11-06 16:18:41 ----

Perhaps we need to write individual bugs for all the particular cases once we
create a framework for this kind of cancelling.



------- Additional Comments From pavel@eazel.com 2000-11-06 22:00:11 ----

This will probably be implemented on a case-by-case basis in each of the
modules.
In file we could get away with not doing anything because the the typical read,
write, etc. operations will take on the order of milliseconds.
For http, ftp, etc. we need to use signalling to interrupt the I/O.



------- Additional Comments From darin@bentspoon.com 2000-11-07 11:31:52 ----

It seems that even in file, we can run into cases where an operation takes a long time, 
like in the case of NFS, or when reading from a floppy or a CD.



------- Additional Comments From snickell@stanford.edu 2001-07-23 00:35:57 ----

Taking bugs previously assigned to Pavel, assigning them to myself. Will parse
them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:45 -------
Comment 1 Maciej Stachowiak 2001-10-07 10:28:57 UTC
It will take some effort to fix this I think. I am not even sure what
a good framework would be.
Comment 2 Manuel Clos 2003-09-28 12:17:34 UTC
In the name lookup case, and perhaps in others too, the timeout can be
very high. Anyway, at some moment it is going to return, isn't it?

Is it a problem to have too many "dead" threads?
Comment 3 Seth Nickell 2004-10-27 03:50:19 UTC
MASS CHANGE VFS. Re-assigning bugs that I currently own in VFS to the proper
owner (probably Alex).
Comment 4 André Klapper 2008-09-06 18:58:36 UTC
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 these notification emails 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