This patch cleans up the DBus utilitys and helper classes. All functions
for sending have been removed. Their users have been converted to the
new methods in RawDBusConnection. Include statements have been cleaned
up as well. Some methods of DBusMessageRefPtr have been moved from the
header to the source file to prevent inclusion of the DBus API from within
the header file.
This patch adds methods for sending DBus messages to the class
RawDBusConnection. There are 3 types of interfaces.
- Send Sends a message over DBus. No error checking or
handling of replies is performed. These methods
do not block the sending thread.
- SendWithReply Sends a message over DBus and runs a call-back
function for the reply. This should be the default
case for most scenarios. These methods do not
block the sending thread.
- SendWithError Sends a message over DBus and waits for the reply
or an error. This interface has only been added for
some existing code that can safely block the sending
thread. Don't use it in new code.
These 3 types of interfaces represent what is currently used of the
existing send functions in DBusUtils. When all users have been converted
to the new methods, the interfaces in DBusUtils can be removed.
Every IPDL C++ class contains a bunch of typedefs.
Every IPDL C++ source file contains a bunch of typedefs and using statements
for the exact same types.
Why is that?
Because the class itself is not in scope for name lookup of return types of C++
methods. This limitation is annoying, but it makes sense. The typedefs and
using statements therefore exist so we can be a little sloppy about return
types.
Let's stop being sloppy and polluting the global namespace inside these
files. Less pollution makes it easier to smash the IPDL files together for
unified compilation. One could do this by qualifying all necessary return
types...or we could just use the C++0x late return syntax, which guarantees the
class *is* in scope for name lookup. I like this version a lot better.
Changes initialization code for the template process:
* Let the process run for NUWA_PREPARATION_TIME ms and then start freezing the threads.
* Delay android binder thread pool creation after the content process is forked from the template and other thread recreation has finished.
* Poke the app shell after the content process is forked from the template.
2013-06-03 18:14:46 +08:00
Thinker Lee ext:(%2C%20Cervantes%20Yu%20%3Ccyu%40mozilla.com%3E)
The threads that are frozen/recreated include:
* ImageBridgeChildThread.
* Image decoding thread pool.
* IPC thread (checkpointed, but not frozen).
* GC Helper thread.
* XPC runtime watchdog thread.
* Socket transport service thread/thread pool.
* Memory pressure watcher.
* Timer thread.
* DOM promise worker.
2013-06-03 18:14:42 +08:00
Thinker Lee ext:(%2C%20Cervantes%20Yu%20%3Ccyu%40mozilla.com%3E)
Changes include:
* Getting/resetting platform thread ID.
* Creating an IPC channel with existing file descriptor sent from the template process.
* Child process host with existing process forked from the template.
The IPC::Message header is surrounded by:
#pragma pack(push,2)
...
#pragma pack(pop)
which (at least on GCC) specifies that structure members defined lexically
within the pragma should be two-byte aligned, rather than the ABI's declared
alignment.
But for IPC::Message::Header, this is a silly requirement, as everything there
is four bytes; there's no reason to pack the members any tighter. And packing
tighter means that strict alignment platforms (like ARM) need to use more
complex code for something as simple as storing to one of the members--like
when we set a message's request ID, over and over and over. The current code
for setting a message's request ID on ARM looks like:
264: 6863 ldr r3, [r4, #4]
266: 696a ldr r2, [r5, #20]
268: 809a strh r2, [r3, #4]
26a: 0c12 lsrs r2, r2, #16
26c: 80da strh r2, [r3, #6]
With the patch, it looks like:
264: 6863 ldr r3, [r4, #4]
266: 696a ldr r2, [r5, #20]
268: 605a str r2, [r3, #4]
Only four bytes, but multiplied over several hundred set_routing_id calls, it
saves some code size and runtime. I verified that the header's length doesn't
change by looking at debug information.
