========
https://hg.mozilla.org/integration/gaia-central/rev/422a64c4639a
Author: Michael Henretty <michael.henretty@gmail.com>
Desc: Revert "Merge pull request #30872 from etiennesegonzac/bug-1179040"
This reverts commit 66638d0e65bf58b7f640bcc7bed4a0b23d1356c6, reversing
changes made to 7676b68b4d32ed13243eeb719188847121bd5611.
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 31 days, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every month. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
This patch finally breaks up forwarding received RIL messages to the
main thread before they go to the RIL worker. Any RIL message that is
received on th I/O thread is forwarded directly to the RIL worker
thread and handed over to the RIL worker JS code.
The patch includes a number of changes. They all depend on each other,
so there's no good way of landing them one-by-one.
* |RilConsumer| now runs on the RIL worker thread.
* |RilWorker| uses tasks to register/unregister |RilConsumer| in the worker.
* |RilConsumer| uses |RilSocket| instead of |StreamSocket|.
* With |RilSocket|, received RIL messages do not go through main. They are
forwared to the RIL worker and handed over to JS immediately.
This patch separates the current interface of |RilConsumer| into
two distinct classes. |RilWorker| provides the public interface
and |RilConsumer| provides the internal implementation. Running
|RilConsumer| on a worker thread will be easier this way.
With this patch, |RilSocket| and it's helpers forward received data
via a WCTD. This will hand over the worker's JS context to the RIL
consumer.
In a later patch, the RIL consumer will be moved onto the RIL worker
thread and call the JS ril-worker code directly.
|RilSocket| and |RilSocketConsumer| are copies of the respective stream-
socket classes. Improvements to the RIL I/O code will be implemented on
top of the new classes.
This causes e10s to behave differently from non e10s, because in e10s we don't
forward the creation of the document to the parent process. However this only
seems to happen in strange edge cases.
