Confirm
431
edits
Changes
Created page with 'At the April 2009 Platform work week we had a meeting on making necko support requests from threads other than the main thread. Here's some design notes on what we came up with....'
At the April 2009 Platform work week we had a meeting on making necko support requests from threads other than the main thread. Here's some design notes on what we came up with.
== A reasonable API target for now: sending OnDataAvailable() to other threads ==
In a perfect world, our goal would be an API where any thread could use the full necko interface, and initiate and process network requests completely independently. However, while there's no theoretical reason why necko couldn't be made fully re-entrant, the implementation obstacles involved would be considerable (see notes at end for some details).
Benjamin Smedberg suggested a much more modest goal: that non-main threads be allowed to directly receive the OnDataAvailable() call from the nsIStreamListener interface. All setup of the network channel before this point (and possibly after) would need to be handled on the main thread.
The meeting quickly came to a consensus that something like this would be sufficient for the existing uses cases for which a multithreaded necko has been requested: most notably, for an off-main-thread HTML parser to be able to stream in HTML from the network without interfering/delaying the main thread (and vice versa).
There still remain, however, some questions about the exact API:
== API Discussion ==
1) Decision to divert data to other thread should be made in OnStartRequest().
There seemed to be general agreement that the decision to offload OnDataAvailable() to a different thread should be made within OnStartRequest(). By this point, we will have the final channel for the request (i.e. any redirects, auth requests, etc, will have been resolved). We will also have the Content-type of the request, which we will need to determine whether the data should be handled by an off-thread consumer (like the HTML parser) in the first place.
2) How to notify other-thread listener when request is complete?
Two obvious ways come to mind. 1) We could also divert OnStopRequest() to the listener's thread. Or, 2) we could send an additional OnDataAvailable() with data length == 0 to signal the end of the Request. #1 is more intuitive for the programmer; #2 is more conservative, in that the main thread will still receive OnStopRequest. Since compliant nsChannels will need to be modified anyway, no one could think of a good reason not to change them to no longer expect OnStopRequest(), and so #1 is the current winner, pending discovery of any problems with not delivering OnStopReq() to the main thread.
3) Need to QI Channel to see if it supports other-thread delivery, and Channel in turn needs to QI chain of Listeners that they are thread-safe.
== Implemention Questions ==
* cache:
== Notes ==
=== Obstacles to a fully-threaded necko API ===
* A large number of classes would need modification: nsURI, nsChannels, IIOService and the various nsIProtocolHandlers.
* Authorization boxes would need to be popped up from non-main threads
* Many of the necko APIs have been implemented by Javascript extensions, which would suddenly need to be thread-safe
== A reasonable API target for now: sending OnDataAvailable() to other threads ==
In a perfect world, our goal would be an API where any thread could use the full necko interface, and initiate and process network requests completely independently. However, while there's no theoretical reason why necko couldn't be made fully re-entrant, the implementation obstacles involved would be considerable (see notes at end for some details).
Benjamin Smedberg suggested a much more modest goal: that non-main threads be allowed to directly receive the OnDataAvailable() call from the nsIStreamListener interface. All setup of the network channel before this point (and possibly after) would need to be handled on the main thread.
The meeting quickly came to a consensus that something like this would be sufficient for the existing uses cases for which a multithreaded necko has been requested: most notably, for an off-main-thread HTML parser to be able to stream in HTML from the network without interfering/delaying the main thread (and vice versa).
There still remain, however, some questions about the exact API:
== API Discussion ==
1) Decision to divert data to other thread should be made in OnStartRequest().
There seemed to be general agreement that the decision to offload OnDataAvailable() to a different thread should be made within OnStartRequest(). By this point, we will have the final channel for the request (i.e. any redirects, auth requests, etc, will have been resolved). We will also have the Content-type of the request, which we will need to determine whether the data should be handled by an off-thread consumer (like the HTML parser) in the first place.
2) How to notify other-thread listener when request is complete?
Two obvious ways come to mind. 1) We could also divert OnStopRequest() to the listener's thread. Or, 2) we could send an additional OnDataAvailable() with data length == 0 to signal the end of the Request. #1 is more intuitive for the programmer; #2 is more conservative, in that the main thread will still receive OnStopRequest. Since compliant nsChannels will need to be modified anyway, no one could think of a good reason not to change them to no longer expect OnStopRequest(), and so #1 is the current winner, pending discovery of any problems with not delivering OnStopReq() to the main thread.
3) Need to QI Channel to see if it supports other-thread delivery, and Channel in turn needs to QI chain of Listeners that they are thread-safe.
== Implemention Questions ==
* cache:
== Notes ==
=== Obstacles to a fully-threaded necko API ===
* A large number of classes would need modification: nsURI, nsChannels, IIOService and the various nsIProtocolHandlers.
* Authorization boxes would need to be popped up from non-main threads
* Many of the necko APIs have been implemented by Javascript extensions, which would suddenly need to be thread-safe
