User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121221 Firefox/20.0 Build ID: 20121221030826 Steps to reproduce: This is a clone of bug 810101. From 810101#c9, there is an unexpected hashstore read being kicked off by nsHttpChannel:BeginConnect. The channel is suspended until the read completes even though the read is off the main thread, which merits investigation. Actual results: The HttpChannel is suspended until the HashStore read completes. Expected results: The HttpChannel should not be suspended

The description needs to be edited to be: "A hashstore read kicked off by nsHttpChannel::BeginConnect suspends the channel even though the read is off the main thread."

This is located in Classifier.cpp in Classifier::Open: // Build the list of know urlclassifier lists // XXX: Disk IO potentially on the main thread during startup RegenActiveTables();

If it's the very first page opened (so the Classifier may still be initializing) then indeed it's not unexpected. Though currently the code checks whether the tables have any subs in them before considering them active. I'm not sure why that check is even needed, and it's the reason the hashstore is opened. BTW. It seems Chrome doesn't block channels at all while SafeBrowsing lookups are outstanding. You can see the phishing page flash before the warning is overlayed. I wonder what we do if you get a hit and the completion server is slow to respond...

One of the areas that we're working on in Snappy is to make startup faster, so from that perspective it would be nice to avoid opening the hashstore on the first page opened (provided it doesn't negatively impact security, of course).

Mark as [qf] since this might be worth looking into from a startup performance point of view.

Henry, do you know if this bug is currently still an issue?

The only connection between nsHttpChannel::BeginConnect() and Classifier::Open() that I can think of is [1]. In the past, the blocking API was used in BeginConnect() to do local URI classification. So, in the first use, nsURLClassifierDBService will be initialized on the main thread, where an event will be posted to a worker thread for reading hashstore, which is NOT blocking the main thread. However, the subsequent call of the blocking API [2], which relies on operations on the worker thread, needs to be waiting until we read out hashstore. In bug 1325054, I have replaced the sync API with the async one [3]. As far as I can tell, that doesn't make hashstore load faster but will not block the main thread any more. [1] http://searchfox.org/mozilla-central/rev/6580dd9a4eb0224773897388dba2ddf5ed7f4216/netwerk/protocol/http/nsHttpChannel.cpp#6012 [2] http://searchfox.org/mozilla-central/rev/6580dd9a4eb0224773897388dba2ddf5ed7f4216/netwerk/base/nsIURIClassifier.idl#87 [3] http://searchfox.org/mozilla-central/rev/6580dd9a4eb0224773897388dba2ddf5ed7f4216/netwerk/base/nsIURIClassifier.idl#96

I would think this is a dup of bug 1325054 which has been fixed.