Xref: utzoo comp.unix.xenix:4801 comp.unix.wizards:14529
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!rutgers!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.xenix,comp.unix.wizards
Subject: Re: Errors in PS
Message-ID: <8869@alice.UUCP>
Date: 5 Feb 89 00:36:09 GMT
References: <19496@lll-winken.LLNL.GOV> <341@belltec.UUCP> <667@pcrat.UUCP> <464@oglvee.UUCP> <9593@smoke.BRL.MIL>
Reply-To: debra@alice.UUCP ()
Organization: AT&T, Bell Labs
Lines: 23

In article <9593@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <464@oglvee.UUCP> jr@.UUCP (Jim Rosenberg) writes:
>>The way that ps works is an utter abortion, IMHO.
>
>Yes; fixed in SVR4 (I think).  Not with more system calls, though.
>Read the paper "Processes as Files" in one of the USENIX proceedings.

This "Processes as Files" way of implementing ps, as done in the Eight
and Ninth edition Unix, does not guarantee flawless behaviour of ps though!

The old remark in some man-pages remains in effect:
"Things can change while ps is running."

The Unix system is not "frozen" while ps is trying to get the info about
the processes. While ps is trying to read info about a process that process
may change states, grow, be swapped out, or die, all of which may confuse
ps. The "ps: seek error" can still occur.

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------