[demrom]

Depends on #192; until it lands this diff also shows its commits, and the new test needs it to finish.

ios_nextAvailablePid hands out one of 127 pids. With all of them taken, the caller looped over the pid table while holding pid_mtx, which ending commands need to free their slot (cleanup_function spins on pthread_mutex_trylock(&pid_mtx)). No slot was ever freed: the other callers blocked in pthread_mutex_lock, the ending commands spun, and ios_waitpid never returned.

A caller that finds no free slot now releases pid_mtx and sleeps on the condition variable ios_waitpid already uses, and the broadcast an ending command already sends wakes it. Cancellation is disabled around that wait, since a thread cancelled in pthread_cond_wait would keep the mutex every ending command takes. Once awake, the caller retakes pid_mtx, rereads the parent command's environment (ios_setenv may have reallocated it meanwhile) and looks for a free slot again.

Test

tests/pid-admission.m starts 200 threads that each run ios_fork, ios_system("hold") and ios_waitpid. hold blocks until the test releases it, so after 127 commands start, the other 73 callers wait for a pid and nothing ends. The test fails if the process uses more than 0.5 s of CPU over the next second: sleeping callers use none, while a caller that loops on the pid table uses a whole core. A watchdog prints the stacks of all threads (tests/hang-dump.h) and exits 124 after 10 seconds without progress.

On the iOS 27 Simulator:

• master (fa2af59) + Hand the current pid back to the parent only when the ending command still owns it #192: 5 of 5 runs fail with FAIL, 0 of 200 commands finished, no progress for 10 s, using 0.96 to 1.00 s of CPU in the 1 s window, with 72 callers in pthread_mutex_lock.
• With this change on the same base: 10 of 10 runs print 200 commands over 127 pids, wall=2.8s PASS to wall=3.1s, with 0.00 s of CPU in the window.

dash in a-Shell never holds 127 pids at once: a pipeline takes one pid, and a & job runs to completion before the next one starts (evalsubshell in dash_iOS src/eval.c). So the pid limit is covered by this Simulator test only.

[holzschu]

That fix makes sense, but it got me wondering: is that an issue that you actually met (and in that case, would it make sense to increase the limit to a higher value? and if so which one?)

[demrom]

Yes, in a stress test, not in normal use. I ran 160 commands at once from separate threads on the Simulator, and all 12 configurations I tried without this change froze: the stacks showed the caller spinning in ios_nextAvailablePid while the ending commands looped on pid_mtx in cleanup_function. tests/pid-admission.m reproduces it with 200 threads.

I'd keep the limit at 128. With this change a caller past the limit waits for a free pid instead of hanging, so the limit only caps how many commands run at the same time. Raising it is cheap: a slot costs about 1 KB of static memory, almost all of it previousDirectory[MAXPATHLEN], so going from 128 to 256 slots adds about 135 KB.

[holzschu]

Thanks for the explanation.