[meta] Allow HttpChannelChild asyncOpen/OnStartRequest/OnStopRequest off main thread
Categories
(Core :: Networking: HTTP, enhancement, P3)
Tracking
()
People
(Reporter: CuveeHsu, Unassigned)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Keywords: meta, Whiteboard: [necko-triaged])
One of the challenge is the loadgroup is not thread safe and we should touch it only on the main thread. Moreover, when we'd like to do something with the notification callback, we are going to ask the loadgroup's notification callback once the channel's callback is not set before AsyncOpen.
Therefore, this enhancement depends on several bugs which should be done soon-ish:
(a) appcache: Currently we pick up an application cache from the notification callbacks if available and pass it to parent.
(b) child process intercept:
The loadgroup has an intercept controller, which should be acquired on the main thread. Fortunately we're going to do the fully parent intercept.
https://searchfox.org/mozilla-central/rev/61fceb7c0729773f544a9656f474e36cd636e5ea/netwerk/protocol/http/HttpChannelChild.cpp#2515-2559
Moreover, we send a top-level window ID to parent process to avoid infinitely prompt. We might either force main thread asyncOpen for all the navigation, or try to query the top-level window ID in the parent process.
Another thing that worries me is private browsing. For a channel without loadgroup and notification callback, we're going to ask for isPrivateBrowsing from loadinfo. Hence we might a lock to see if mLoadGroup and mCallback are both null, and that hurts performace we want to enhance here.
That brings another topic: should we put loadinfo for target thread only? Now loadinfo is not thread safe, but I haven't check much if there's anything we need to make it thread safe. Redirect is the thing come to my mind that we want it to handle in main thread now.
Reporter | ||
Comment 1•4 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•