Closed Bug 898694 Opened 11 years ago Closed 2 years ago

Enable indexedDB to do IO in child process

Categories

(Core :: Storage: IndexedDB, defect, P5)

x86
macOS
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: sicking, Unassigned)

References

Details

(Whiteboard: [MemShrink:P3])

Right now IDB always proxies calls to the parent process when reads/write to/from the filesystem is happening. This has a couple of problems.

First off it means that we're putting more load on the parent process as far as CPU usage goes.

Second, it means that when we do the IO, we end up with multiple copies of the data in memory at the same time. At least two of which are in the parent process. First the data in sqlite. Then the copy in ipdl as we send the data to the child process. Then either the parent or the child (or both?) caches for future reads.

We should enable the child process to instead do the IO directly. For now that means that the parent process needs to open the file handle, and then clone it to the child process. This since child processes doesn't have access to open files in B2G.

We will still have to deal with multiple child processes accessing the same database. This definitely means that we have to do transaction scheduling in the parent process. And it likely means that we have to close the database file between each transaction.
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P3]
Priority: -- → P5

While this high level concept may be revisited in the future, this specific architectural change is unlikely to happen, especially given fission explicitly supporting multiple processes for each origin and limitations on our ability to do quota management for write purposes.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.