David Laight wrote in <[email protected]>: |From: Steffen Nurpmeso |> Sent: 01 March 2022 17:49 |> 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". | |Nothing stops pids going beyond 16 bits. |(Apart from some of the very old emulations.) |Much like nothing really requires the pid allocator to even start |allocating linearly (after giving init pid 1) - but that is |rather expected. | |I can't remember at which point it went above 32767. |Was over 20 years ago when I wrote it :-)
Ah, kernel. Not my league then :-) (I knew the (Linux) sysctl/proc entry, but it is unchanged here.) --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
