jonbakke
commented
2 years ago Fantastic comment. Thank you.
I had looked at sigchld() and attempted to divine its intent, but failed. I now have cmd() performing zombie-removal duties along with its memory cleanup, and it looks like only a few zombies now remain at any given time for each browser instance.
If you want to do the same in surf, I'd try adding the line -- waitpid(-1, NULL, WNOHANG); -- somewhere in spawn().
Do let me know if this doesn't clean it up for you.
In surf, every instance of a spawning of the dmenu URI and find functions results in a Z-state sh process, that is unkillable, of course. These takes up about nothing in RAM or CPU, so unless one never closes one's surf instance/s, one can in practice spawn and cancel go and or find prompts to get to the the maximum number of pids---
</proc/sys/kernel/pid_max1---, after which I assume the OS get confused.I wanted to see if boredserf's behavior with regards to the above is different---it is. Using
ps -exo state | grep Z | wc -lbefore and after starting a boredserf, the increment here is 5, rather than 0, like in surf's case. The URI prompts increment by 1 again, but the find ones do so by 2.Without the Zs, I currently have 197 pids taken up, I don't know how likely it is that somebody would run out of pids nowadays. It's also unlikely for somebody to spawn
(2^15 (or 2^22, for 64-bit OSs) - 200) / 56.5k (838k) instances of boredserf, or use find/go 5 times those amounts before closing, but it may be prudent to think about.