26302 - OpenInputStream produces a blocking stream.

Status: VERIFIED INVALID

(Core Graveyard :: RDF, defect, P3)

Description

[Judson Valeski]

http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFXMLDataSource.cpp#581
and
http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFXMLDataSource.cpp#581
and
http://lxr.mozilla.org/seamonkey/source/rdf/content/src/nsXULDocument.cpp#4744 
and
http://lxr.mozilla.org/seamonkey/source/rdf/content/src/nsXULKeyListener.cpp#118
1

show lines using the channel->OpenInputStream() api. The result is that the user 
is handed an input stream to read data from. The inputStream->Read() call is a 
blocking call and can/will block the thread it's called on. If this steam is 
guaranteed to be read from a thread other than the UI thread, evaluate whether 
or not the blocking behavior is ok, and if so, close this bug. Otherwise, your 
code need to do an asynchronous load of the URI. If you don't want to implement 
nsIStreamListener, please look at nsIStreamLoader.idl which will call a callback 
function you implement when all the data has arrived (it does all the 
asyncronous work for you).

Comment 1

[Chris Waterson]

These are meant to be synchronous. And yes, I know it's a loaded gun. :-)

Is this causing other problems? Or can I mark this as a non-bug?

Comment 2

[Judson Valeski]

well... does this code get called. If so I'm actually suprised it even works. 
Protocol level OpenInputStream implementations should deadlock the UI thread.

Comment 3

[Chris Waterson]

it gets called in very special places :-). seriously, this is how we 
synchronously load RDF data files at startup (e.g., all the chrome registry 
stuff and XBL stuff). it's been around for a long, long time.

why should the protocol implementations deadlock the UI thread?

Comment 4

[Judson Valeski]

protocol impls of OpenInputSTream() use a SyncStreamListener. This thing is an 
async streamlistener on one end and a pipe on the other. The transports fire 
events over onto the UI thread (where OpenInputStream() is called) when they 
have data to feed the pipe. If the UI thread is blocked (on a stream->Read() 
call) these events obviously can't be digested, thus deadlock. Does this code 
access data over the network, or is it typically file? If the latter we may be 
feeding the pipe fast enough that you never block. But then we're exposed if we 
start doing net URLs.

Comment 5

[Chris Waterson]

while there is potential for misuse of the API (e.g., you could tell a network 
URL to load synchronously), the only places we use it currently are for loading 
local data that we really do need to be there to start up.

I think I tried a remote URL once, and the HTTP protocol handler said, "I can't 
let you do that, Dave."

Comment 6

[Judson Valeski]

marking this invalid. waterson knows he's waving a match over a pool of 
gasoline; *and* not to let it get too close.

Comment 7

[Tom Everingham]

verified Invalid

Comment 8

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/d206d6b2a504
[fenix] For https://github.com/mozilla-mobile/fenix/issues/26302 - Change header text height to wrap_content for autofill add/edit screens