On Sun, Mar 15, 2020 at 03:36:39PM +0700, Robert Elz wrote:
> The NetBSD shell - and I suspect many others, perhaps all others, waits
> for any terminated children (reaps them from the kernel) more or less as
> soon as they exit - then remembers the info in the internal jobs table
> for later repor
Schwarz, Konrad wrote in
:
|> -Original Message-
|> From: Robert Elz
|> Sent: Sunday, March 15, 2020 13:47
|> To: shwaresyst
|> Cc: austin-group-l@opengroup.org
|> Subject: Re: Weird possibility with async processes, $!, and long \
|> running scripts
|>
Date:Mon, 16 Mar 2020 13:38:58 +0100
From:Joerg Schilling
Message-ID: <5e6f7362.u+rw3m3sirjpta0s%joerg.schill...@fokus.fraunhofer.de>
| Do you like to talk about what happens when pid numbers are reused?
Yes.
| This may be a negative side-effect of PID ramomizat
Robert Elz wrote:
> Date:Sun, 15 Mar 2020 11:39:27 + (UTC)
> From:shwaresyst
> Message-ID: <1641208969.3419054.1584272367...@mail.yahoo.com>
>
> | For that purpose both still running processes and zombie processes have
> | to be considered as active where new
Robert Elz wrote:
> Consider
>
> bg-process-1 & PID1=$!
> long-running-monster-fg-process
> bg-process-2 & PID2=$!
>
> "long-running-monster-fg-orocess" is something like a complete system
> build, including lots of add-on utilities (imagine, gnome and all that
> goes with it, a
> -Original Message-
> From: Robert Elz
> Sent: Sunday, March 15, 2020 13:47
> To: shwaresyst
> Cc: austin-group-l@opengroup.org
> Subject: Re: Weird possibility with async processes, $!, and long running
> scripts
>
> Date:Sun, 15 Mar 2020 11:3
Date:Sun, 15 Mar 2020 11:39:27 + (UTC)
From:shwaresyst
Message-ID: <1641208969.3419054.1584272367...@mail.yahoo.com>
| For that purpose both still running processes and zombie processes have
| to be considered as active where new ID selection would be concerne
For the example provided I think you are right it is a potential issue in that
the shell only specifies that commands will be in a separate execution
environment, without being explicit the requirement of fork() to keep process
IDs unique applies to these environments. It just has that the envi
On 15/03/2020 08:36, Robert Elz wrote:
I'd love to hear from anyone who has (or can even imagine, regardless of
whether it is currently implemented anywhere) a better solution for this
issue. Or if for some reason I am not understanding this isn't even a
potential (certainly it is extremely unl
The NetBSD shell - and I suspect many others, perhaps all others, waits
for any terminated children (reaps them from the kernel) more or less as
soon as they exit - then remembers the info in the internal jobs table
for later reporting status via "wait $pid" or "jobs" (or just an
interactive promp
10 matches
Mail list logo