[9fans] waitpid()

[9fans] waitpid()

[lucio]

Posix waitpid() seemingly can select the PID to wait for.  Unlike P9
waitpid(2) which merely returns the PID.

It has always baffled me that originally Unix allowed one to wait for
a child to complete without providing a mechanism to select _which_
child.  In other words, I side with Posix on this issue but I would be
curious to know why what seems obvious to me (in hindsight of course)
was not the design in the first place.

Of some importance is the fact that the current APE implementation has
an understandably faulty waitpid(): it removes PIDs it does not (yet)
care about while looking from the requested one.  When one later goes
looking for one of these discarded PIDs, it naturally does not get
found.

It is unmanageable to cache PIDs somehow within APE wait model,
because it is difficult (unless I miss something) if not impossible to
track PID as children terminate, so they can be added to the cache by
the time a process comes looking for them.

So the big question is whether it is entirely out of the question to
enhance the kernel "wait" functionality so that something resembling
Posix waitpid() can return the termination information for a chosen
PID.

I have not looked at the kernel myself, but until the historical
reasons have been shown to be insignificant, I'm not the best person
to investigate this.

++L

Re: [9fans] waitpid()

[Fco.J.Ballesteros]

> Posix waitpid() seemingly can select the PID to wait for.  Unlike P9
> waitpid(2) which merely returns the PID.

My question is, what does posix say regarding the pids
you don't want. I mean, does it say something like

"when waitpid finds an unwanted pid it guarantees that such
information is not dropped" or the opposite, or just nothing about.
Perhaps rsc knows.

Regarding what should be done, I think that all waitpid() variants
should be dropped. The regular wait one is the one that should
be there IMHO. If you just happen to be looking for a particular
pid, then put your wait() in a lopp. If you also happen to want to
keep the unwanted ones around (should you want to wait for them
in the future), record them in a list.

The plan9 waitpid is a convenience for the case when you look for
a pid but don't care about others. Thus, I wouldn't vote for changing
the native interface; I'd just change ape, but only if posix says so.
Otherwise I'd fix the program using ape.

Re: [9fans] waitpid()

[lucio]

> The plan9 waitpid is a convenience for the case when you look for
> a pid but don't care about others. Thus, I wouldn't vote for changing
> the native interface; I'd just change ape, but only if posix says so.
> Otherwise I'd fix the program using ape.

I hope I'm not reading it wrong: P9 waitpid(2) is a stripped down
version of wait(2) that returns only the "current" PID, no other
details.  It has nothing in common with Posix waitpid().

++L

Re: [9fans] waitpid()

[lucio]

> My question is, what does posix say regarding the pids
> you don't want. I mean, does it say something like
> 
> "when waitpid finds an unwanted pid it guarantees that such
> information is not dropped" or the opposite, or just nothing about.

The NetBSD man page is a bit ambiguous, but I think waitpid() and
wait4() specifically wait for the given PID and no other.  Remember
that the child need not have terminated yet, so you may not want to
return at all and carry on waiting even though other children have
terminated (don't ask!).

++L

Re: [9fans] waitpid()

[lucio]

> The NetBSD man page is a bit ambiguous, but I think waitpid() and

This might help:

	http://netbsd.gw.com/cgi-bin/man-cgi?wait+2+NetBSD-current

++L

Re: [9fans] waitpid()

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 60 bytes --]

Sorry. I meant the bsd waitpid and not the plan 9 waitpid.

[-- Attachment #2: Type: message/rfc822, Size: 2416 bytes --]

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] waitpid()
Date: Fri, 16 Apr 2004 11:03:16 +0200
Message-ID: <098cc449668fabc366ee4852e9cfbaff@proxima.alt.za>

> The plan9 waitpid is a convenience for the case when you look for
> a pid but don't care about others. Thus, I wouldn't vote for changing
> the native interface; I'd just change ape, but only if posix says so.
> Otherwise I'd fix the program using ape.

I hope I'm not reading it wrong: P9 waitpid(2) is a stripped down
version of wait(2) that returns only the "current" PID, no other
details.  It has nothing in common with Posix waitpid().

++L

Re: [9fans] waitpid()

[boyd, rounin]

> So the big question is whether it is entirely out of the question to
> enhance the kernel "wait" functionality so that something resembling
> Posix waitpid() can return the termination information for a chosen
> PID.

don't do it in kernel mode.  do it in user mode.  just record the
pid + Waitmsg of the ones that wait has returned and search
this first and if not found go into a wait loop, recording the
pid + Waitmsg as wait returns if it's not the one you want,
otherwise return.

    The Waitmsg structure is allocated by malloc(2) and
    should be freed after use. For programs that only need
    the pid of the exiting program, waitpid returns just the
    pid and discards the rest of the information.

http://plan9.bell-labs.com/magic/man2html/2/wait

Re: [9fans] waitpid()

[lucio]

> don't do it in kernel mode.  do it in user mode.  just record the
> pid + Waitmsg of the ones that wait has returned and search
> this first and if not found go into a wait loop, recording the
> pid + Waitmsg as wait returns if it's not the one you want,
> otherwise return.

Hm, I thought it couldn't be done, but the above makes sense.  Now if
I just had rob's skills with linked lists...

I'll report back.

++L

Re: [9fans] waitpid()

[boyd, rounin]

> Hm, I thought it couldn't be done, but the above makes sense.  Now if

well i thought i'd coded it before.

look at pipe.c:

    http://www.insultant.net/repo/plan9/mace.bundle

1st Ed, 2 day rush job port done in 1994.

Re: [9fans] waitpid()

[lucio]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

> well i thought i'd coded it before.
> 
> look at pipe.c:

Thanks, Boyd, for the guidelines and also to Nemo for suggesting a
similar tack in previous private mail.

I have no idea whether this is adequate, but it matches some
superficial expectations, at least.

I'm including my efforts here because I'm going away for the weekend
and somebody may have the opportunity in the meantime to look at the
code and use it, but more specially to inspect it and hopefully make
suggestions on how to improve it (other than in code layout, I have a
great deal of trouble omitting spaces as seems to be the norm in Plan
9 sources, sorry about that).

I'll be grateful for all and any feedback, please be alerted that the
code is designed for use in the APE environment, modelled on the
NetBSD wait(2) man page I mentioned earlier.  It is intended to
replace

	/sys/src/ape/lib/ap/plan9/wait.c

in its entirety, but I have not checked this to any degree.  The
module compiles and runs with

	$ pcc -D_PLAN9_SOURCE -D_POSIX_SOURCE -I/sys/src/ape/lib/ap/plan9 -c pidwait.c
	$ 8l -o pidwait pidwait.8
	$ pidwait

from my home directory.

++L

[-- Attachment #2: pidwait.c --]
[-- Type: text/plain, Size: 3069 bytes --]

#include "lib.h"
#include <stdlib.h>
#include <sys/wait.h>
#include <sys/stat.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include "sys9.h"

pid_t wait(int *status);

pid_t waitpid(pid_t wpid, int *status, int options);

pid_t wait3(int *status, int options, Waitmsg *waitmsg);

pid_t wait4(pid_t wpid, int *status, int options, Waitmsg *waitmsg);

/*
**	PID cache
*/
typedef struct wdesc wdesc;
struct wdesc {
	pid_t w_pid;
	Waitmsg *w_msg;
	wdesc *w_next;
};
static wdesc *wd = 0;

static Waitmsg *
lookpid (pid_t pid) {
	wdesc **wp0 = &wd, *wp;
	Waitmsg *msg;

printf ("PID+ %d ", pid);

	if (pid == -1) {
		if (wd == 0)
			return 0;
		pid = wd->w_pid;
	}
	for (wp = wd; wp; wp = wp->w_next) {
printf ("looking: %d.", wp->w_pid);
		if (wp->w_pid == pid) {
			msg = wp->w_msg;
			*wp0 = wp->w_next;
printf (" yes\n");
			free (wp);
			return msg;
		}
		wp0 = &(wp->w_next);
	}
printf (" no\n");
	return 0;
}

static void
addpid (Waitmsg *msg) {
	wdesc **wp0 = &wd, *wp = malloc (sizeof (wdesc));

printf ("ADD: %d\n", msg->pid);
	wp->w_msg = msg;
	wp->w_pid = msg->pid;
	wp->w_next = wd;
	wd = wp;
}

pid_t
wait (int *status) {
	return wait4(-1, status, 0, 0);
}

pid_t
waitpid (pid_t wpid, int *status, int options) {
	return wait4(wpid, status, options, 0);
}

pid_t
wait3 (int *status, int options, Waitmsg *waitmsg) {
	return wait4(-1, status, options, waitmsg);
}

pid_t
wait4 (pid_t wpid, int *status, int options, Waitmsg *waitmsg) {
	Waitmsg *w;

	if (options & WNOHANG) {
		char pname[128];
		int i;
		struct stat buf;

		snprintf (pname, sizeof (pname), "/proc/%d/wait", getpid());
		i = stat (pname, &buf);
		if (i >= 0 && buf.st_size == 0)
			return 0;
	}
	if (w = lookpid (wpid)) {
		waitmsg = w;
		wpid = w->pid;
		return wpid;
	}
	w = _WAIT();
	while (w) {
		if (wpid <= 0) {
			waitmsg = w;
			wpid = w->pid;
			return wpid;
		}
		if (w->pid == wpid) {
			if (status) {
				int r = 0;
				int t = 0;
				char *bp, *ep;

				if (w->msg[0]) {
					/* message is 'prog pid:string' */
					bp = w->msg;
					while (*bp) {
						if (*bp++ == ':')
							break;
					}
					if (*bp == 0)
						bp = w->msg;
					r = strtol (bp, &ep, 10);
					if (*ep == 0) {
						if (r < 0 || r >= 256)
							r = 1;
					} else {
						t = _stringsig (bp);
						if (t == 0)
							r = 1;
					}
				}
				*status = (r << 8) | t;
			}
			waitmsg = w;
			wpid = w->pid;
			return wpid;
		} else {
			addpid (w);
		}
		w = _WAIT();
	}
	if (w == 0) {
		_syserrno ();
	}
}

#define N (5)

main () {
	int x, status;
	pid_t p, pid[N];
	Waitmsg waitmsg;

	for (x = 0; x < N; x++) {
		switch (pid[x] = fork()) {
			case 0:
				sleep (5);
				exit (0);
			case -1:
				_syserrno ();
				break;
			default:
				sleep (3);
				break;
		}
		printf ("ID[%d]: %d\n", x, pid[x]);
	}
	for (x = 0; x < N; x++) {
		if (p = wait4 (pid[x], &status, 0, &waitmsg))
			printf ("PID[%d]: %d\n", x, p);
	}
}

Re: [9fans] waitpid()

[boyd, rounin]

> Thanks, Boyd, for the guidelines and also to Nemo for suggesting a
> similar tack in previous private mail.

i could of used a list but NOFILE was small when i wrote the original,
so an array more than sufficed.

wait4() -- therein lies madness.

Re: [9fans] waitpid()

[lucio]

> wait4() -- therein lies madness.

Probably, but it is merely a generalisation.  I doubt it is used much
directly and it does not defeat the original intentions.  Pity about
the name, really.

++L