26303 - OpenInputStream produces a blocking stream.

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Judson Valeski]

http://lxr.mozilla.org/seamonkey/source/layout/xbl/src/nsXBLService.cpp#425

shows a line 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

[David Hyatt]

not a problem.

Comment 2

[Judson Valeski]

does this thing load net based URL's? If so it can cause UI thread dead lock. 
The protocols use a SyncStreamListener() underneath to mimic the sync behavior. 
That object is a pipe on one end (the stream's end) and a stream listener on the 
other so it can receive the data async even thought the user get's it 
synchronously. The transports fire events to the SyncSTreamListener to get the 
data into the pipe, if the caller of OpenInputSTream calls ->Read() on the 
returned stream and blocks, no events can get through and thus deadlock.

Comment 3

[David Hyatt]

Potentially, but not in anything we'll use it for (we'll always be using local 
files for chrome in 5.0).  If you want to reopen it that's fine, but I won't get 
to it before we ship.