jpage@rruxa.UUCP (J Page) (01/12/88)
UNIX Wizards: Anyone on the net have any suggestions, or ideas on how to emulate the 4.2BSD wait3() system call under System V??? If it helps we are on a Pyramid 9810 under OS/x 4.0. Thanks in advance, Jim Page ihnp4!bellcore!rruxe!jpage
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/12/88)
In article <360@rruxa.UUCP> jpage@rruxa.UUCP (J Page) writes: >UNIX Wizards: Anyone on the net have any suggestions, or ideas on > how to emulate the 4.2BSD wait3() system call under System V??? Basically, you can't, at least not with the current release. > If it helps we are on a Pyramid 9810 under OS/x 4.0. One would think that there would be a way to execute UCB system calls from the ATT environment, but perhaps (for security reasons?) Pyramid hasn't provided one.
perry@phoenix.Princeton.EDU (Kevin R. Perry) (01/13/88)
In article <360@rruxa.UUCP> jpage@rruxa.UUCP (J Page) writes: >UNIX Wizards: Anyone on the net have any suggestions, or ideas on > how to emulate the 4.2BSD wait3() system call under System V??? > > If it helps we are on a Pyramid 9810 under OS/x 4.0. ...And I'd like to know the same thing, only I need to implement wait3() on a Silicon Graphics IRIS. Kevin Perry perry@phoenix.princeton.edu
romain@pyrnj.uucp (Romain Kang) (01/14/88)
In article <360@rruxa.UUCP> jpage@rruxa.UUCP (J Page) writes: | UNIX Wizards: Anyone on the net have any suggestions, or ideas on | how to emulate the 4.2BSD wait3() system call under System V??? | | If it helps we are on a Pyramid 9810 under OS/x 4.0. Pyramid is a special case because the wait3() call is available from the kernel if you give the right syscall number, regardless of whether your program is in the UCB or ATT universe. You could punt and link UCB wait3.o with your ATT binary. In System V make, you can grab wait3() with wait3.o: /.ucblib/libc.a(wait3.o) ar x /.ucblib/libc.a wait3.o This is completely nonportable, of course. -- Romain Kang {allegra,cmcl2,pyramid,rutgers}!pyrnj!romain Pyramid Technology Corp. / 10 Woodbridge Center Dr. / Woodbridge, NJ 07095
news@jpusa1.UUCP (usenet) (01/15/88)
In article <7060@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: -In article <360@rruxa.UUCP> jpage@rruxa.UUCP (J Page) writes: ->UNIX Wizards: Anyone on the net have any suggestions, or ideas on -> how to emulate the 4.2BSD wait3() system call under System V??? - -Basically, you can't, at least not with the current release. - It depends on what you're trying to do. If all you need is a nonblocking wait you can do something like: noop(){;} nonblockingwait() { int i, w; int (*oldsig)() = signal(SIGALRM, noop); int oldalrm = alarm(1); i = wait(&w); alarm(0); signal(SIGALRM, oldsig); alarm(oldalrm); ... } -- Stu Heiss {gargoyle,ihnp4}!jpusa1!stu
jh@pcsbst (01/18/88)
The newer versions of System V provide the possibilty to check
the existence of a process by sending a signal 0 to the process
in question and checking for an error return. This would allow
you to write a write a pseudo wait3() function for terminated
processes:
int wait3_for_sysV (testpid, status, options, rusage)
int testpid;
union wait * status;
int options;
struct rusage * rusage; /* not used */
{
....
if (options & WNOHANG) {
if (kill (testpid, 0) == -1) {
if (errno != EPERM)
return (wait (status));
else
return (BUG);
} else {
return (STILLRUNNING);
}
} else {
return (wait (status));
}
}
This is only an example. Check for possible different error
returns of the kill() system call. For a better implementation
you should poll all pids in question.
I hope this did help you.
Johannes Heuft
unido!pcsbst!jhrml@hpfcdc.HP.COM (Bob Lenk) (01/27/88)
> The newer versions of System V provide the possibilty to check > the existence of a process by sending a signal 0 to the process > in question and checking for an error return. This would allow > you to write a write a pseudo wait3() function for terminated > processes: All versions of System V (and System III) permit the use of signal 0. However, at least through V.2.* (and I haven't checked V.3.* but wouldn't expect a change) kill() permits killing a zombie. This is different from BSD, where kill() returns ESRCH on attempts to kill a zombie. Bob Lenk {ihnp4, hplabs}!hpfcla!rml
meissner@xyzzy.UUCP (Michael Meissner) (01/28/88)
In article <4200004@pcsbst.UUCP> jh@pcsbst writes: > The newer versions of System V provide the possibilty to check > the existence of a process by sending a signal 0 to the process > in question and checking for an error return. This would allow > you to write a write a pseudo wait3() function for terminated > processes: While this scheme will work 99.9999999% of the time, there is a small hole -- the process could die, and it's terminatation would be available, and subsequent to that, the system could reuse the process ID. If you were superuser, you would not get back the error return that the pid isn't yours. Granted, it takes awhile for the system to reuse pids (about 30,000 generally). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa/Csnet: meissner@dg-rtp.DG.COM
jh@pcsbst (01/29/88)
It is not true that a process id is not unique, even for a dead process in the zombi state. In AT&T System V.[23] a zombi process keeps its process id (pid) until it is really eliminated by wait() (or ignoring SIGCLD). Thus, the process id is not reused when creating a new process and the technique for a pseudo wait3() in SVR[23] should work 100% ok. Johannes Heuft unido!pcsbst!jh
jh@pcsbst (02/01/88)
Ok, flame me! Indeed, SRV[32] allows killing of a zombi process (see AT&T code). This is not what I expected, maybe I got mixed up with some BSD code. Excuse me for the noise. Thus, my suggestion of a pseudo-wait3() has to go to /dev/null. However, looking some more into the code, one finds that the process group of a zombi process is set to 0 (surprise?!). Which leads me to the conclusion that if a processes indead calls setprgp() you can test its state by kill (-childpid, 0) provided that the process did not create some children which did not call setpgrp(). Having burned may fingers once, I do no suggest any scheme based on this fact. However, one question: where is the consistency here?! Johannes Heuft unido!pcsbst!jh
davel@hpcupt1.HP.COM (Dave Lennert) (02/04/88)
> However, looking some more into the code, one finds that the > process group of a zombi process is set to 0 (surprise?!). > Which leads me to the conclusion that if a processes indead > calls setprgp() you can test its state by > > kill (-childpid, 0) > > provided that the process did not create some children > which did not call setpgrp(). You assume that the zombie process of interest was formerly a process group leader (process group ID == process ID). This is not necessarily the case. You are probably thinking that, csh's that support BSD-style job control, the first command in a pipeline is always made a process group leader. This is not true on shells that do not do this style of job control, and thus is not true on System V (at least not yet). -Dave Lennert HP ihnp4!hplabs!hpda!davel