Xref: utzoo comp.unix.wizards:24024 comp.unix.programmer:1021
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!mahendo!wlbr!voder!pyramid!ctnews!risky!pase70!scottl
From: scott@convergent.com (Scott Lurndal)
Newsgroups: comp.unix.wizards,comp.unix.programmer
Subject: Re: deamon help
Message-ID: <2827@risky.Convergent.COM>
Date: 7 Feb 91 22:14:39 GMT
References: <594@edpmgt.UUCP> <BZS.91Feb5105600@world.std.com> <2304@inews.intel.com> <19032@rpp386.cactus.org>
Sender: root@risky.Convergent.COM
Reply-To: scott@convergent.com (Scott Lurndal)
Organization: Unisys Network Computing Group
Lines: 23

|> In article <2304@inews.intel.com> bhoughto@hopi.intel.com (Blair P. Houghton) writes:
|> >In article <BZS.91Feb5105600@world.std.com> bzs@world.std.com (Barry Shein) writes:
|> >>For a problem like this I'll bet you a nickel crafting the whole thing
|> >>in C using /dev/kmem etc will not be much faster than the above
|> >>described script, and will take a week to get right instead of 30 minutes.
|> >
|> >Better, use popen(3) and top(1).  Top usually gets the data
|> >much faster than ps.  Why?  Who knows?  Could be anything
|> >from superior skills among public-domain software developers
|> >to abuse of /dev/null.
|> 

Actually the best solution would be to use the /proc file system code if you 
have a SVR4.0 system.   Use opendir(3)/readdir(3) to fetch each process number, 
open it, issue a PIOCPSINFO ioctl(2), and close it.   The PIOCPSINFO ioctl(2) will
return the system and user times in seconds and nanoseconds (amongst other things).  
This should be sufficient resolution to determine whether the process 
is really doing anything.

Be aware that although the resolution of the field is in nanoseconds, 
some systems may only support micro or milli-second resolution.

Scott.