Specifically:
* SandboxCrash() uses internal Gecko interfaces, so stays in libxul.
* SandboxInfo moves to libxul from libmozsandbox, which no longer exists.
* Where libxul calls Set*Sandbox(), it uses weak symbols.
* Everything remains as it was on mobile.
Similarly to part, there's no need to say we don't know the routing id
when constructing a message, and then turn around and set the routing id
immediately afterwards. Just let the constructor do its work.
The default constructor for ipdl-generated messages looks like:
MOZ_IMPLICIT Msg_AsyncMessage() :
IPC::Message(MSG_ROUTING_NONE, ID, IPC::Message::PRIORITY_NORMAL, COMPRESSION_NONE, "PContent::Msg_AsyncMessage")
{
}
IPC::Message::PRIORITY_NORMAL is 1, so any set_priority(1) calls are
just redudant.
Additionally, the priorities for messages are known at code generation
time, so we are always able to provide the right constants to the
message constructor, rather than using set_priority calls later.
Modern OSs adjust process scheduling based on CPU-boundedness and Interface-boundedness. A process performing a lot of UI tasks requires lower-latency than a CPU-bound process. For this reason, at least on Windows (but probably also Linux and Mac), in e10s, resize events are sent at a much higher rate than non-e10s, where the main process has to do the work to respond to them. This was supposed to be handled by the 'compress' option in IPDL but its duplicate-event test was very imprecise - it only tested the *oldest* message in the queue. This patch searches the messagequeue/deque to remove *any* duplicate. deque::erase is linear but this is a very uncommon case - currently only two compressed IPDL messages exist in the entire code base. Also, these queues are small.
This patch adds |BluetoothDaemonConnection|, which transfers PDUs from and
to the Bluetooth daemon. The class is build around the existing socket I/O
infrastructure.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
