1) Find a host that is not reachable.  That means DNS resolution is possible,
but pinging the hostname never returns a response.  ipchains magic may make it
possible to construct this  case
2) Type in that host in the Nautilus URI bar
3) Hit "Cancel"

Expected:
	Navigation stops
Actual:
	Nautilus UI Freezes (probably for TCP timeout)

What's going on:

The Gnome-VFS HTTP method is blocking indefinitely on a connect().  It holds a
semaphore on the the GnomeVFS cancellation context.

The main thread of Nautilus calls gnome_vfs_async_cancel().  It blocks
indefinitely waiting for the semaphore.

Proposed fixes:

1) GnomeVFS connect() and read() abstractions could be set to non-blocking mode
and spin checking for cancellating event.  This does not handle the case where
gethostbyname() blocks

2) gnome_vfs_async_cancel could disconnect callback stuff but schedule the job
cleanup for later.  This seems more complicated but more complete.



------- Additional Comments From pavel@eazel.com 2001-02-06 18:09:02 ----

3) use signal to unblock the call. As Mike points out, signal behaves quirky in
that it behaves non-portably on different implementations. If the set of
differences was manageable, this would be a good solution though because you
would end up interrupting a call that othewise locks up resources faster.



------- Additional Comments From mikef@praxis.etla.net 2001-02-06 18:14:50 ----

Very similar to 6290



------- Additional Comments From mikef@praxis.etla.net 2001-02-06 18:16:04 ----

pavel--

Oh yeah, I don't think a signal will bail out gethostbyname, but then I don't
know if the job lock is called in the case where gethostbyname is called 




------- Additional Comments From sullivan@eazel.com 2001-02-07 09:49:55 ----

Seems necessary for 1.0.



------- Additional Comments From mikef@praxis.etla.net 2001-02-10 22:15:42 ----

*** Bug 46268 has been marked as a duplicate of this bug. ***



------- Additional Comments From yakk@yakk.net 2001-02-16 18:57:58 ----

*** Bug 46472 has been marked as a duplicate of this bug. ***



------- Additional Comments From don@eazel.com 2001-02-20 08:55:35 ----

Why isn't this a duplicate of bug #44573?




------- Additional Comments From darin@bentspoon.com 2001-02-20 11:57:40 ----

It's reasonable to guess that this might be a duplicate of bug 44573, but I don't
think there is clear evidence to prove that.



------- Additional Comments From mikef@praxis.etla.net 2001-02-20 13:38:58 ----

To pavel, to add to his doom.

Due to the bad behaviour of gethostbyname (see bug 44573) it would be best if
this were fixed so that gnome_vfs_async_cancel doesn't block, even though the
thread may hang around for a while.

Removing dependency on 4573




------- Additional Comments From mikef@praxis.etla.net 2001-02-20 13:40:11 ----

(to respond to darin and don's comments:  4573 is one of the things that can
*cause* this bug, but it is not the only thing.  And fixing 4573 is not the only
or best way to fix this bug)



------- Additional Comments From don@eazel.com 2001-02-20 20:33:53 ----

Making "gnome_vfs_async_cancel" not block seems like a large task to be tackling
now.  Can this really be done in a day?




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:59 -------
Bug blocks bug(s) 41974 44019 46711.

The original owner (pavel@eazel.com) of this bug does not have an account here.
Reassigning to the default owner of the component, yakk@yakk.net.