wait for non-child PID

wait for non-child PID

[Tanaka Akira]

I heard that wait has a problem if the argument is non-child PID.

For example,

% wait 1

blocks forever.  (It is interruptible.)

bash detects that the PID is not child of the shell.

bash-2.04$ wait 1
bash: wait: pid 1 is not a child of this shell
-- 
Tanaka Akira

Re: wait for non-child PID

[Clint Adams]

> % wait 1
> 
> blocks forever.  (It is interruptible.)
> 
> bash detects that the PID is not child of the shell.

I'm glad that zsh's wait will wait on processes that aren't children of the
shell.  Is there a reason that it shouldn't?

Re: wait for non-child PID

[Tanaka Akira]

In article <20000726190953.A22895@scowler.net>,
  Clint Adams <schizo@debian.org> writes:

> I'm glad that zsh's wait will wait on processes that aren't children of the
> shell.  Is there a reason that it shouldn't?

A zsh can waits the process, but the zsh doesn't notice its status
change because the zsh is not the parent of it and SIGCHLD cannot
reached to the zsh.  Is it useful?
-- 
Tanaka Akira

PATCH (?): Re: wait for non-child PID

[Bart Schaefer]

On Jul 26,  6:06pm, Tanaka Akira wrote:
}
} I heard that wait has a problem if the argument is non-child PID.
} [Zsh] blocks forever.  (It is interruptible.)
} 
} bash detects that the PID is not child of the shell.

Hmm, this is an interesting portability problem.  Zsh does sometimes
create child processes that it might conceivably be reasonable for a
script to wait for, but that are not listed in its job tables.  So
there's no obvious internal way to check whether a PID is a child, and
we can't rely on waitpid() or wait4() being available.

A quick check with strace (without looking at source) shows that bash
reports "is not a child" without using any system calls, so it must be
using a table of child process IDs.

On Jul 26,  7:09pm, Clint Adams wrote:
}
} I'm glad that zsh's wait will wait on processes that aren't children of the
} shell.  Is there a reason that it shouldn't?

One obvious counter-example is `wait $$' ...

The `wait' builtin uses zsh's waitforpid() function, which loops doing
kill(pid,0) to make sure the process is still running, and if so rather
than use wait4() or the like (see above) it does a sigpause() or the
equivalent.  The kill will eventually fail for any process that exits;
but zsh only comes out of the sigpause() when it gets a signal of some
kind, which may never happen if the waited-for pid is not a child.

On Jul 27,  2:13pm, Tanaka Akira wrote:
} 
} A zsh can waits the process, but the zsh doesn't notice its status
} change because the zsh is not the parent of it and SIGCHLD cannot
} reached to the zsh.  Is it useful?

It's certainly not useful as currently implemented.  It'd at least have
to recognize that waiting when (pid == 1 || pid == getpid()) is silly,
and it'd have to use a polling time-out for any PID that is not known
to be a child.

Short of doing that, the only thing to do seems to be to rely on the job
table.  I won't commit the following patch until we're reasonably sure
that there are no interesting cases of child processes that can't be
detected by findproc() -- something I'm not entirely certain of myself.

Also, we might want to change the error message to be ksh-like rather
than bash-like, if there's a difference.

Note in passing:  bash prints "bash: wait: ..." but zwarnnam() prints
only "wait: ..." and zwarn() prints only "zsh: ...".  Oh, well.

Index: Src/jobs.c
===================================================================
@@ -1289,7 +1289,13 @@
 
 	if (func == BIN_WAIT && isanum(*argv)) {
 	    /* wait can take a pid; the others can't. */
-	    waitforpid((long)atoi(*argv));
+	    pid_t pid = (long)atoi(*argv);
+	    Job j;
+	    Process p;
+	    if (findproc(pid, &j, &p))
+		waitforpid(pid);
+	    else
+		zwarnnam(name, "pid %d is not a child of this shell", 0, pid);
 	    retval = lastval2;
 	    thisjob = ocj;
 	    continue;

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH (?): Re: wait for non-child PID

[Bart Schaefer]

On Jul 27,  6:57am, Bart Schaefer wrote:
}
} Short of doing that, the only thing to do seems to be to rely on the job
} table.  I won't commit the following patch until we're reasonably sure
} that there are no interesting cases of child processes that can't be
} detected by findproc() -- something I'm not entirely certain of myself.

Anybody have anything to say about this?  If nobody knows the answer, then
maybe instead I should commit it and we can watch for things that break.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH (?): Re: wait for non-child PID

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jul 27,  6:57am, Bart Schaefer wrote:
> }
> } Short of doing that, the only thing to do seems to be to rely on the job
> } table.  I won't commit the following patch until we're reasonably sure
> } that there are no interesting cases of child processes that can't be
> } detected by findproc() -- something I'm not entirely certain of myself.
> 
> Anybody have anything to say about this?  If nobody knows the answer, then
> maybe instead I should commit it and we can watch for things that break.

Sorry, forgot to answer this...

Yes, I think you should just apply it. Since findproc() is the
function used by the signal handler to find the job this is probably
the best we can do.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de