Confirm
431
edits
Changes
m
-- * 3/6/13: jduell: note this this would mean that any addons that use nsITraceableChannel.setNewListener() (noscript and 71 other addons according to mxr) would silently revert any channels they hook to using main-thread delivery. That sucks. And in general any JS listeners are not going to be able to handle off-main thread delivery. JST suggests we simply fail setNewListener if the new listener is JS (i.e. QI's to nsIXPCWrappedJS). Another possibility is that we add a different asyncOpenToThread() call that takes a different kind of nsIRequestObserver-like IDL, and/or which winds up triggering different (or no) on-modify-request-(offmainthread) notifications. The trick is that we were planning to allow the main vs non-main decision to be delayed until OnStartRequest and that's late in the game... Hmm...
→API Discussion
3) Code would need to query both the nsIChannel and any StreamListeners chained (via nsITraceableChannel) between the nsIChannel and the target listener, to make sure they are ALL safe to be switched to a different thread for OnDataAvailable. (We could modify any relevant existing internal listeners to become safe, but since some listeners could come from extensions, we cannot guarantee all listeners will always be safe). Code must be prepared to handle the case where OnDataAvailable cannot be redirected to the desired thread.
4) The API would probably consist of two new XPCOM interfaces, one for thread-retargetable Channels, one for Listeners (nsIThreadSinkableChannel and nsIThreadSinkableStreamListener?). The Channel interface would have a method (RedirectDeliveryToThread?) that would take a thread object argument, and redirect OnDataAvailable (and OnStopRequest) to that thread. The method would first check the chain of Listeners to ensure that they are all ThreadSink listeners, else the method would fail and the redirect would not happen.
