While debugging bug 695309, I discovered that we have some serious issues with pending URI queue, particularly in the face of unexpected connection interruptions. Bug 695309 is itself the primary symptom of this issue, and the patch on said bug is only a band-aid which prevents the problems from causing severe pain. My basic proposal is to use the following notes for the connection queue: 1. If a connection is closed, we should have some logic to see if reopening the connection to run URIs is feasible. 2. If a connection is closed, we should attempt to re-run the URI on another connection. 3. Timeouts should be handled differently: we should first see if the socket is probably usable and timeout if the socket was closed by the other end, instead of assuming that 3 minutes is an automatic timeout. 4. Standard newsgroup updates should not be allowed to take over all of the connections, and probably should be limited to 1 or 2 connections. 5. If a request for a URI comes into the queue, and it is already present, we should consolidate them to one request (and probably move it to the head, unless it's a get-new-messages request).

So the implementation I'd like to see here would use nsISocketTransport::IsAlive, which is documented as being threadsafe but actually isn't. Since NNTP does everything on the main thread for now at least, would it actually be safe to use this?

(In reply to Joshua Cranmer [:jcranmer] from comment #1) > So the implementation I'd like to see here would use > nsISocketTransport::IsAlive, which is documented as being threadsafe but > actually isn't. Since NNTP does everything on the main thread for now at > least, would it actually be safe to use this? Brian would know for sure...

The short answer I got from Brian over IRC is that it is safe to call ::IsAlive on the thread that is doing the I/O, which in this case is the main thread.