Using a private DBus connection gives each of its users, such as
Bluetooth, its own connection to the DBus server. This simplifies
the use of DBusWatch structures and ensures that all resources of
a connection are free'd when the connection gets closed.
Bluetooth maintains two connections to the DBus server and the DBus
system itself maintains a third one. This implies some overhead and
makes the code more difficult to understand.
This patch changes the Bluetooth code to use the connection that is
established by the DBus system.
- HAVE_RANDOM is not checked at all.
- HAVE_STRERROR is not checked in code built using the defines from the main
configure.
- HAVE_LCHOWN is only checked in nsinstall.c, which means the test is also wrong
since it's checking for the target instead of the host. Also, lchown is only
used of the -o and -g options of nsinstall, which, as far as I know, we don't
use (and if we were, that would fail with nsinstall.py, which explicitly rejects
them).
- HAVE_FCHMOD is only checked in nsinstall.c, so same as above about the
correctness of the check. If it's not available, nsinstall.c falls back to
chmod, which is fine enough for our use.
- HAVE_SNPRINTF is not checked.
- HAVE_MEMMOVE is checked in parser/expat/lib/xmlparse.c, but it's also
unconditionally defined in expat_config.h which is included from that file.
- HAVE_SETBUF is checked in a couple files, but setbuf is C89 and C99, I think
it's safe to assume all compilers we support are C89 and C99. Interestingly,
windows does have it, but since we skip this check on windows, we don't use it.
- HAVE_ISATTY, same as HAVE_SETBUF, except it's POSIX instead of C89/C99.
- HAVE_FLOCKFILE is not checked at all.
- HAVE_STRTOK_R is not checked.
- HAVE_FT_SELECT_SIZE is not checked.
- HAVE_DLADDR is not checked under js/src.
- HAVE_GETPAGESIZE is not checked under js/src (it is in libffi, but ffi uses
its own configure)
- HAVE_LSTAT64, HAVE_STAT64, HAVE_STATVFS, HAVE_STATVFS64, HAVE_TRUNCATE64 are
not checked under js/src.
- HAVE_SBRK is not checked under js/src. Moreover,
js/src/assembler/wtf/Platform.h defines it depending on the platform.
- HAVE_SNPRINTF is not checked under js/src.
- HAVE_HYPOT is not checked under js/src.
- HAVE__UNWIND_BACKTRACE is not checked under js/src.
UnixSocketImpl, which mostly runs on the I/O thread, doesn't control
its reference to UnixSocketConsumer. If the connection status is
stored in UnixSocketConsumer, the I/O thread can't read it safely.
This patch duplicates the connection status in UnixSocketImpl, where
reading from the I/O thread is safe. Methods of UnixSocketImpl don't
need to access mConsumer any longer to obtain the connection status.
This is where the magic starts to happen. We move includes from the base
protocol header (${NAME}.h) to the parent and child headers (${NAME}Parent.h
and ${NAME}Child.h) to follow good include hygiene.
For the base protocol header, we examine the set of types used by struct and
union definitions to determine which headers we need to include.
For parent and child headers, we forward declare what we can and include
appropriate headers otherwise. For forward-declared types, we include the
appropriate headers in the parent and child source files.
When computing what set of includes a header file needs, we need to know
about all types that protocol-defined types use, not just qualified
ones: both global-scope names and same-namespace-as-protocol names are
valid to use without any sort of qualification. This flag would normally
not be used in generating actual C++ code and therefore defaults to False.
Keep the builtin headers separate from the translation unit's headers.
We do this so when we start twiddling with the translation unit's headers,
we don't have to handle cases where those headers are actually builtin
headers.
DBusWatcher::Poll currently breaks after reading DBus data from the
socket. Thus, it never processes the data and dispatches the DBus
messages. This patch fixes the code to dispatch DBus messages after
reading the DBus socket.
This patch changes the DBus shutdown to only cleanup the DBus
thread from the main thread after DBusWatcher has completed.
This should ensure that the main thread will not have to wait
for the DBus thread.
--HG--
extra : rebase_source : 09ebb40a4e515ef5b0ebddfc1c3b7187cc546313
PollFdComparator, DBusEventTypes and flag conversion are only used by
DBusWatcher. This patch moves them into DBusWatcher's namespace.
--HG--
extra : rebase_source : 688403e55e139440e6d6d28e9802f8a48d7c355d
The Stop method encapsulates the code for sending the exit command
to a running DBus watcher.
--HG--
extra : rebase_source : 6963e6fa60b2e1e725046672a45cd325fc40a836
The DBus poll functionality is actually part of DBusWatcher. This
patch moves it to a class method.
--HG--
extra : rebase_source : 012813cf1d0967d6c29f7e085e49940570e1d58d
This patch renames DBusThread to DBusWatcher to make its purpose
more clear. Several callback functions for DBus are converted to
methods of DBusWatcher. Their POSIX calls are now protected by
TEMP_FAILURE_RETRY.
--HG--
extra : rebase_source : d8c6963aa8388c462917180d78e8e4289f9e987a
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.
