Hello. ..despite that particular timeout(1), i have not looked..
David Laight wrote in <[email protected]>: |From: Denys Vlasenko |> Sent: 01 March 2022 16:40 |> On Tue, Feb 15, 2022 at 12:31 PM Rob Landley <[email protected]> wrote: |>> On 2/14/22 10:09 AM, Roberto A. Foglietta wrote: ... |> My memory is hazy on this, but IIRC kernel also actually has some |> defensive code to not immediately reuse pids which just died. | |The Linux krnel only has protection for code inside the kernel. |Basically there is a ref-counted structure that you need to send the |signal - not the pid itself. |I can't quite remember whether the pid itself can be reused even before |that structure is freed. | |NetBSD does guarantee not to reuse a pid for a reasonable number |of forks after a process exits. ...which might be fruitless with 16-bit pids, define "reasonable". Matt Dillon of DragonFly BSD (crond etc.) made, after implementing some DBSD kernel optimizations (iirc), tests with statically linked programs and... quoting myself i remember Matthew Dillon's post on DragonFly BSD users@[1], where he claims 450000 execs per second for a statically linked binary, and about 45000 execs per second for a dynamic one, with DragonFly 5.6 on a threadripper. [1] https://marc.info/?l=dragonfly-users&m=155846667020624&w=2 (Hope that is still valid.) It think it is a problem with shells, i once stumbled over this with a particular (now completely rewritten) of the test suite of the mailer i maintain: My guess would have been that if i kill(1) a job specification, then the sh(1)ell would refuse to use its builtin kill(1) to kill a PID that was saved away from ${!}, and the process in question has already terminated. Of course using job specifications is impossible here, let alone portably (though that i have not even tried, because set -m results in a lot of unwanted noise). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
