Return to Question

Sorry then my question becomes: is this by design? I have never heard of the caveat of continuously create background job. The only solution I know so far is use disown to stop managing the background jobs, or use other tricks such as (cmd&) to start a process without being managed as background job.

EDIT: The above test2 is still the most interesting question, why it does not run out of memory?

Sorry then my question becomes: is this by design? I have never heard of the caveat of continuously create background job. The only solution I know so far is use disown to stop managing the background jobs, or use other tricks such as (cmd&) to start a process without being managed as background job.

EDIT: answered by myself: this should be by design, it just means Bash tracking all active jobs, if in a short period, there are a lot of active jobs, then it runs out of memory. So this is not contradictory to the test2.

This is an evidence that the Bash wait command use the cache (I'v also use strace to verify that, it clearly showed the syscall wait4 returned -1.

wait4(-1, 0x7ffd79fc3fd0, WNOHANG, NULL) = -1 ECHILD (No child processes)

This is an evidence that the Bash wait command use the cache (I'v also use strace to verify that, it clearly showed the last syscall of wait4 returned -1.

wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 9}], 0, NULL) = 397
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 399
wait4(-1, 0x7ffd79fc3fd0, WNOHANG, NULL) = -1 ECHILD (No child processes)

The result will be

The result is