Robert Elz <k...@munnari.oz.au> 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, and kde, and all associated with that ...) - it doesn't
> really matter, except that there are lots of processes being run.
> It is irrelevant whether that is lots of childrem from the current
> shell, or whether that is a script (or "make" or something) that simply
> takes a long time to complete.
>
> In this case, and with the shell strategy above, it is possible that
> PID1 and PID2 contain the same value.
Do you like to talk about what happens when pid numbers are reused?
This may be a negative side-effect of PID ramomization that could reuse
pis numbers much earlier than without...
> Does anyone know of a shell that correctly handles this now?
I guess there is no behavior that could be called "correct", since the behavior
is not caused by the shell but by the kernel.
Before talking about your ideas, it would be important to define what you
intend.
Solaris defines PID_MAX to 999999. What value are you using?
> The only solutions I can see are to:
>
> We always use wait*() with the WNOWAIT flag when waiting for any random
> child to complete, and then wait() again (wthout WNOWAIT, but with the
> explicit pid) when we want to clean up the jobs table entry for that job.
>
> The problem with this (aside from WNOWAIT in the standard only applying
> to waitid() - in practice I suspect that all of the wait*() sys calls
In fact, there are platforms (AIX IIRC) that implement waitid() flags only with
waitid(), but why do you care about outdated interfaces anyway?
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
