[meta] Centralize URI parsing and make it threadsafe
Categories
(Core :: Networking, defect, P5)
Tracking
()
Performance Impact | none |
People
(Reporter: sicking, Unassigned)
References
(Depends on 4 open bugs, Blocks 3 open bugs)
Details
(Keywords: meta, perf, Whiteboard: [necko-would-take])
We'd really like to make more code runnable on worker threads. One of the things that we basically always need anytime we're interacting with necko is dealing with nsIURIs. However since nsIURIs currently can be implemented by addons, and created through addon-provided factories, we can neither create nsIURIs or interact with them off the main thread. However the whole idea of having addons provide nsIURI parser, just means that we're encouraging more different ways of parsing URIs. More unity would be good. So what we could do is something like this: * Remove nsIProtocolHandler.newURI * Add some way for a protocol handlers to declare if they want to use a nsIURI or nsIURL. I.e. if they want to be parsed using a plain URI parser or one that supports hierarchical directories. Possibly other metadata would need to be signaled too. * Make nsIURI and nsIURL immutable. * Write a single URI parser which is used to parse all URIs. Initially we probably need that parser to carry over all quirky differences between parsing of chrome:// and resource:// etc. * Make said parser available off the main thread by caching metadata about custom schemes in a threadsafe hash. Once we have done that we should also do * Change our parsers to match the URL spec that's currently in the works. * Remove the differences between our various hierarchical parsers as to increase code reuse. Another nice-to-have is: * Make our error handling more consistent so that URI handling either fails at nsIURI-parse time, or that it fails after nsIChannel::AsyncOpen has been called. I.e. ideally creating an nsIChannel from a URI, and calling AsyncOpen on it should always succeed.
Reporter | ||
Comment 1•11 years ago
|
||
https://mxr.mozilla.org/addons/search?string=contract%2B%40mozilla.org/network/protocol%3B1%3Fname lists 59 addons that would likely need to be updated. An alternative approach here would be to keep nsIProtocolHandler.newURI, but only use it when URIs are created from the main thread. For off-main-thread creations of URIs we'd only support internal schemes as well as schemes that were added through the declarative form in bullet two above. For such off-main-thread URIs we'd make the nsIURI immutable using nsIMutable. We could also add warnings whenever a URI was created using nsIProtocolHandler.newURI but that there was no declarative equivalent. That way the above list can hopefully be shortened. We could likewise add warnings to all nsIURI mutators in order to phase out mutable URIs.
Comment 2•11 years ago
|
||
> * Add some way for a protocol handlers to declare if they want to use a nsIURI
> or nsIURL. I.e. if they want to be parsed using a plain URI parser or one that
> supports hierarchical directories. Possibly other metadata would need to be
> signaled too.
Is protocolFlags insufficient?
Reporter | ||
Comment 3•11 years ago
|
||
URI_NORELATIVE might indeed be enough to tell if we should use hierarchical url parsing or "plain" parsing.
Comment 4•11 years ago
|
||
> Is protocolFlags insufficient?
Yes. What's needed is a _declarative_ way that doesn't involve calling into protocol-handler-provided code at URI parse time.
Precaching all the protocolFlags for all protocol handlers in the system would work, but we have no way to enumerate them right now.
Reporter | ||
Comment 5•11 years ago
|
||
What would a declarative way look like if it's not some form of function/getter on nsIProtocolHandler? We can always proxy to the main thread whenever get a request for a new scheme for the first time. Though that does suck complexity and performance wise.
Comment 6•11 years ago
|
||
> What would a declarative way look like
For example, something registered with an XPCOM category whose contents we can just read at startup. This can include calling code, of course, as long as we only do that on the main thread...
Given category observers, we can even allow dynamic addition/removal.
Updated•8 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
This may affect comm-central as we probably also define some URI protocols.
Updated•7 years ago
|
Comment 9•7 years ago
|
||
[qf-]. Sadly this isn't something we can do for 57 because of add-on compatibility issues.
Comment 10•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Updated•5 years ago
|
Comment 12•5 years ago
|
||
With bug 1536744 closed I think we can officially call this project complete.
The remaining bugs are just usability/performance improvements.
Comment 13•5 years ago
|
||
If you're not already planning to, would it be possible to send a mail to dev-platform about this and any limitations people should still be aware of? I think it would be great to both recognize this fantastic achievement and also help perhaps surface any further plans about allowing principal creation from any thread/etc. in a way that's visible to everyone interested in the platform. Thanks!
Comment 14•5 years ago
|
||
(In reply to Andrew Sutherland [:asuth] (he/him) from comment #13)
If you're not already planning to, would it be possible to send a mail to dev-platform
https://groups.google.com/forum/#!topic/mozilla.dev.platform/ILkf8vTRZsI
Updated•2 years ago
|
Description
•