Closed
Bug 1226432
Opened 9 years ago
Closed 8 years ago
Add a synchronous version of RemoteOpenFile
Categories
(Core :: Networking: JAR, defect)
Core
Networking: JAR
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jduell.mcbugs, Unassigned)
References
Details
Attachments
(1 file)
2.01 KB,
text/plain
|
Details |
So certain loads of CSS require synchronous Open(), and they're failing in e10s because our hack-y RemoteOpenFile implementation doesn't provide it. (See the attached IRC chat and bug 1179536 for details) It looks like the fastest path to a fix for now at least is to implement a version of RemoteOpenFile that does the "send IPDL to parent, open fd, and return it to child" synchronously. This will require at a minimum a new IPDL protocol. The existing PRemoteOpenFile.ipdl uses the constructor & destructor to request/receive the fd, but that's async. So instead we'll need a regular constructor/destructor, and a sync RemoteOpen() method that returns an fd. I suspect we'll want to move all the nsIFile functions and any other shared logic from RemoteOpenFileChild to a new base class that both RemoteOpenFileChild and RemoteSyncOpenFileChild inherit from, so we don't have to duplicate all that logic. RemoteOpenFileChild currently calls into TabChild::GetCachedFileDescriptor() to see if the fd is already cached at that layer. We could either change that API to a synchronous one instead of a listener (AFAICT remoteOpen is the only user of the API), or we could probably just skip checking the Tabchild (the tabchild cache is only used when LoadURI is called, which is for top-level loads, which we don't care about here).
Reporter | ||
Comment 1•8 years ago
|
||
Fabrice: can you give us a test case that shows where this is failing today? That would be handy for knowing whether we've fixed this (and ideally we won't have to write a new test).
Flags: needinfo?(fabrice)
Comment 2•8 years ago
|
||
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #1) > Fabrice: can you give us a test case that shows where this is failing today? > That would be handy for knowing whether we've fixed this (and ideally we > won't have to write a new test). Not really, because that fails only when we do an open() as the first request in a jar. Once the jar is cached things "work". Until we get a memory pressure event, and flush the cache, and that happens on b2g.
Flags: needinfo?(fabrice)
Reporter | ||
Comment 3•8 years ago
|
||
No big deal: we'll just use one of the existing libjar xpcshell tests in e10s mode to test this code.
Updated•8 years ago
|
Whiteboard: [necko-would-take]
Reporter | ||
Comment 4•8 years ago
|
||
This feature was just for the app:// protocol, which is now toast.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [necko-would-take]
You need to log in
before you can comment on or make changes to this bug.
Description
•