Rodrigo Damazio Bovendorp <rdamazio@google.com> [Thu, 07 May 2020 03:14:52 -0700] rev 44781
procutil: always waiting on child processes to prevent zombies with 'hg serve'
When runbgcommand is invoked by an extension with ensurestart=False, we never
called waitpid - which is fine in most cases, except if that's happening on a
command server (e.g. chg), in which case the child defunct process will just
sit there for as long as the server is running.
The actual semantics of SIGCHLD signal handling is a lot more complex than
it seems, and the POSIX standard *seems* to read that it's ignored by default
and everything would just work without the waitpid if we're not listening for
it, but the truth is that it's only ignored if we *explicitly* set it to
SIG_IGN. We further cannot set it to SIG_IGN or to a catch-all handler across
all of 'hg serve', because Python's suprocess.Popen relies on that signal,
and a few specific parts of hg also set custom handlers, so instead we wait
for specific PIDs in dedicated threads.
I did a poor-man's benchmark of the thread creation and it seems to take
about 1ms, which is way better than the 20+ms from ensurestart=True.
Differential Revision: https://phab.mercurial-scm.org/D8497
Joerg Sonnenberger <joerg@bec.de> [Thu, 07 May 2020 15:00:33 +0200] rev 44780
tests: use regular POSIX shell
wait-on-file requires one POSIX extension (sleep with non-integral
argument), but it doesn't require any bash extensions, so just require a
normal POSIX shell. While here, use consistent formatting without
redundant ;
Differential Revision: https://phab.mercurial-scm.org/D8500
Raphaël Gomès <rgomes@octobus.net> [Thu, 07 May 2020 10:15:19 +0200] rev 44779
rust-regex: increase the DFA size limit for the `regex` crate
`re2`'s DFA limit is already increased in `rust/hg-core/src/re2/rust_re2.cpp`,
the same has to be done for the `regex` crate.
Big repositories with big `.hgignore`s will sometimes hit this limit and face
extreme performance regressions (I've seen one take *minutes* for `hg status`).
Differential Revision: https://phab.mercurial-scm.org/D8499
Augie Fackler <augie@google.com> [Mon, 04 May 2020 10:06:53 -0400] rev 44778
merge with stable
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 01 May 2020 21:47:39 +0530] rev 44777
Added signature for changeset cf3e07d7648a
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 01 May 2020 21:47:30 +0530] rev 44776
Added tag 5.4 for changeset cf3e07d7648a
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Apr 2020 19:23:12 -0400] rev 44775
tests: clarify a comment describing a phabricator test scenario
Per review feedback.
Differential Revision: https://phab.mercurial-scm.org/D8455
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Apr 2020 19:05:25 -0400] rev 44774
phabricator: ensure that `phabsend` is given a contiguous, linear commit range
Supplying a non-linear range was another orphan factory. While in theory there
could be a use case for skipping over garbage commits (like adding debugging)
and getting the valuable commits extracted out at the same time as posting a
review, it seems far more likely that specifying a non-linear range is a user
error. This is another case of issue6045, but predates both 0680b8a1992a and
601ce5392cb0.
Neither the `--no-amend` case nor resubmitting a previously submitted commit
would cause orphans. But for the sake of simplicity and to keep the parents
tracked on Phabricator in the proper state, ban missing commits unconditionally.
Differential Revision: https://phab.mercurial-scm.org/D8454
Martin von Zweigbergk <martinvonz@google.com> [Fri, 01 May 2020 08:07:25 -0700] rev 44773
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Apr 2020 12:37:43 -0700] rev 44772
automation: support building Python 3 MSI installers
This is very similar to what we just did for Inno.
Differential Revision: https://phab.mercurial-scm.org/D8484