Han Xin <hanxin.hx@xxxxxxxxxxxxx> writes:
> We will use the lazy prerequisite ULIMIT_PROCESSES in a follow-up
> commit.
>
> With run_with_limited_processses() we can limit forking subprocesses and
> fail reliably in some test cases.
>
> Signed-off-by: Han Xin <hanxin.hx@xxxxxxxxxxxxx>
> ---
> t/test-lib.sh | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 8ba5ca1534..f920e3b0ae 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1816,6 +1816,15 @@ test_lazy_prereq ULIMIT_FILE_DESCRIPTORS '
> run_with_limited_open_files true
> '
>
> +run_with_limited_processses () {
> + (ulimit -u 512 && "$@")
The "-u" presumably is a way to say that the current user can have
only 512 processes at once that is supported by bash and ksh? dash
seems to use "-p" for this but "-p" of course means something
completely different to other shells (and is read-only), which is a
mess X-<.
I suspect that it is OK to make it practically bash-only, but then ...
> +}
> +
> +test_lazy_prereq ULIMIT_PROCESSES '
> + test_have_prereq !HPPA,!MINGW,!CYGWIN &&
> + run_with_limited_processses true
... as this lazy-prereq makes a trial run that would fail when the
system does not allow "ulimit -u 512", do we need the platform
specific prereq check? I am wondering if the second line alone is
sufficient.
Also, 512 is not a number I would exactly call "limit forking".
Does it have to be so high, I wonder. Of course it cannot be so low
like 3 or 8 or even 32, as per-user limitation counts your window
manager and shells running in other windows.
What you ideally want is an option that lets you limit the number of
processes the shell that issued the ulimit call can spawn
simultaneously, but I didn't find it in "man bash/dash/ksh".
> +'
> +
> build_option () {
> git version --build-options |
> sed -ne "s/^$1: //p"
