From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <f4842ac25caa131d85c944aca3e1e7c8@proxima.alt.za>
To: 9fans@cse.psu.edu
From: lucio@proxima.alt.za
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] waitpid()
Date: Fri, 16 Apr 2004 10:04:29 +0200
Topicbox-Message-UUID: 5d08b60e-eacd-11e9-9e20-41e7f4b1d025

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