Subject: Re: wait(2) suggestion
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 12/27/2004 01:55:27
In article <200412270142.UAA15507@Sparkle.Rodents.Montreal.QC.CA>,
der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:
>>> I found myself wanting an analog to MSG_PEEK for wait(), largely so
>>> as to make it possible to do "wait for a child to die/stop, but
>>> don't reap/mark it" call,
>>> So I invented one: WNOREAP.
>> It is called WNOWAIT and it has already been implemented (I think).
>Well, you're right and you're wrong.
>You're right that WNOWAIT exists and has been implemented, and that
>it's related to what I wanted. You're right that I missed it (which
>you didn't quite say, and actually might not even have meant for all I
>know). But you're wrong that it's what I wanted.
>WNOWAIT is the "don't mark stopped child as waited-for" part of what I
>wanted. But it doesn't do the "don't reap zombies" part; a WNOWAIT
>wait that finds a zombie will still reap it. (I suspect it's designed
>to be used with WNOZOMBIE, which does avoid reaping zombies, but also
>avoids noticing them altogether.)
I'll have to check. It was first implemented as part of compat_svr4 and
was meant to have the same semantics with solaris. The best thing to do
is look at the solaris documentation and make sure that our WNOWAIT and
WNOZOMBIE match what they do. Then if we still need the functionality of
WNOREAP we can add it.
>For my purposes I never want to change any process's state; I just want
>the call to block until something is available that a similar wait,
>without the flag bit, would return. (My WNOREAP returns the status and
>PID, but that's unnecessary for my current application - an accident of
>the implementation, as it were.)
Can't you use kqueue?