Confirmed users
431
edits
Necko: Electrolysis design and subprojects: Difference between revisions
Necko: Electrolysis design and subprojects (view source)
Revision as of 18:11, 24 May 2010
, 24 May 2010→Running
m (→HTTPS) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 34: | Line 34: | ||
# Request from a child process | # Request from a child process | ||
#* The basic design for requests from child processes is that they should "wrap" a regular request on the parent, using IPDL. In other words, we hope to keep the existing nsHttpChannel, nsHttpHandler, etc. code as unmodified as possible; this code should not need to know whether it is servicing a child or a parent request. The logic for supporting a child request should be handled within the IPDL protocol classes instead whenever possible (for instance, HttpChannelParent). | #* The basic design for requests from child processes is that they should "wrap" a regular request on the parent, using IPDL. In other words, we hope to keep the existing nsHttpChannel, nsHttpHandler, etc. code as unmodified as possible; this code should not need to know whether it is servicing a child or a parent request. The logic for supporting a child request should be handled within the IPDL protocol classes instead whenever possible (for instance, HttpChannelParent). | ||
#** Some of the existing necko architecture will exist in both the parent/child, and will need to know at some times where they are running; for instance, nsHttpHandler needs to know whether to hand out an nsHttpChannel (if it's in the parent) or an HttpChannelChild (if it's in the child). For this there is a IsNeckoChild() function, which returns true if called within the child process. | #** Some of the existing necko architecture will exist in both the parent/child, and will need to know at some times where they are running; for instance, nsHttpHandler needs to know whether to hand out an nsHttpChannel (if it's in the parent) or an HttpChannelChild (if it's in the child). For this there is a IsNeckoChild() function, which returns true if called within the child process. For certain optimizations (ex: consolidating OnDataAvail and OnStatus/OnProgress into one IPDL message) it is also useful for the chrome nsHttpChannel to know if it is servicing a remote child request: this is true if "mRemoteChannel" is set. | ||
=== Sync and async IPC messages === | === Sync and async IPC messages === | ||
| Line 55: | Line 52: | ||
=== Running === | === Running === | ||
The necko e10s code is currently turned | The necko e10s code is currently turned on by default in the e10s tree. You can also revert to our starting point mode, where each child process gets its own full necko stack (more feature-complete, but takes up more memory, and separate processes will not have a synchronized cookie database), by setting NECKO_SEPARATE_STACKS in your environment). This is mainly useful only if you're trying to test something other than necko, but the e10s/necko code doesn't yet implement some feature that you need. | ||
Depending on what you're trying to do, you'll either be running [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests or the [https://wiki.mozilla.org/Content_Processes/Build remote tab demo] (a.k.a. test-ipc.xul). Running xpcshell tests is quite lightweight (text-based, and fewer XPCOM things to load, so fast to run on a remote machine over ssh, etc.), while test-ipc.xul fires up a version of the whole browser. Develop with xpcshell when you can (unfortunately some important features--like load groups, notifications, etc.--are not tested by xpcshell, so you currently need to run test-ipc.xul). | Depending on what you're trying to do, you'll either be running [https://developer.mozilla.org/en/Writing_xpcshell-based_unit_tests xpcshell] tests or the [https://wiki.mozilla.org/Content_Processes/Build remote tab demo] (a.k.a. test-ipc.xul). Running xpcshell tests is quite lightweight (text-based, and fewer XPCOM things to load, so fast to run on a remote machine over ssh, etc.), while test-ipc.xul fires up a version of the whole browser. Develop with xpcshell when you can (unfortunately some important features--like load groups, notifications, etc.--are not tested by xpcshell, so you currently need to run test-ipc.xul). | ||
| Line 101: | Line 98: | ||
e10s will hopefully only need minor mods for HTTPS. | e10s will hopefully only need minor mods for HTTPS. | ||
* One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel. Shouldn't need to actually read security info--see what exactly is needed. | * One issue: to determine if Lock Icon needed, content process will need handle to securityInfo, which is currently pointed to by nsHttpChannel. Shouldn't need to actually read security info--see what exactly is needed. | ||
==== Download Manager ==== | |||
The download manager should live in the chrome process. The chrome process is responsible for displaying "Where do you want to save this file?" and should be responsible for the network transfer and disk access. | |||
Issues arise in this architecture (as I understand it) because currently necko actually primarily resides in content processes. | |||
In the ideal world, necko would live in the chrome process entirely and would proxy requests for content processes. Content processes would "subscribe" to the kinds of content they're able to handle for a given request, and if no handler is subscribed, the download manager should be invoked. | |||
How should this work in the existing incarnation of necko/e10s? | |||
==== LoadGroups ==== | ==== LoadGroups ==== | ||