We are trying to port our application (http://www.cs.wisc.edu/
condor) to OSX
10.4 and are having trouble finding an alternative to task_for_pid()
and
task_info(). Condor uses the information provided by these to keep
track of
processes running on the execution nodes. On Linux, Solaris, and other
systems, we usually retrieve this information from /proc.
I have been able to get almost all the information we need out of
kinfo_proc
returned from sysctl except for memory usage. Others have
recommended that
one pipes in the process information from 'ps':
Yes; this was my recommendation. The primary use in this case was to
enable periodic checks of a relatively high latency interval. That's
a good use for "ps". Another one is to find the "Bundle Identifier"
for a process that, had it wanted you to know it's "Bundle
Identifier", it's author would have written it into a file in /var/
run, and you could read it from there.
Your use is somewhat different. I'm not sure I agree that this is a
strictly necessary exercise, given the way our VM works, but if you
think you need it, it's possible for you to get.
This is not a viable option because we there may be many processes
spawned by
a job and we will be calling this section of the code many times a
minute.
Calling 'ps' is significantly slower than accessing the internal data
structures. In a simple test of 10,000 unique process lookups, using
task_for_pid() is almost instantenous while 'ps' takes a full minute.
Note that this problem only occurs when the application's daemons
are not run
with root privileges. The system works fine when running as root,
since we
have the appropriate privileges to execute task_for_pid().
You also have rights to obtain it for your own process.
Is there a better/faster way to get process information in the new
Intel OSX,
in particular the image size and the resident set size, without
using 'ps'?
Or should we just tell our users to install our software and make
sure that
the appropriate user for the system is added to the procmod group?
Since you are spawning the process off, presumably you are the parent
for the process.
If this is the case, then you can:
(1) fork
(2) obtain the task port in the child, prior to execve (the child has
self rights)
(3) send the port from the child to the parent process (the parent can
then use the port)
(4) execve normally (whatever you execve doesn't have to know about
the port)
(5) use the port in the parent process to call task_info() for the task
If your application is actually that performance critical, it actually
doesn't make a lot of sense to ask for the task port each and every
time you need to look for information; if you are introspecting the
data that frequently, then you might as well grab a port and hold onto
it for as long as you need to.
Note that there are certain situations (e.g. SUID binaries being
execve'ed) where you are going to lose rights to the port; if you need
to run such binaries, you will need to run them as root.
Again, I'd like to point out that if you can live without this
information, you should try to do so; for example, if your intent is
to get the information to calculate some figure of merit for machine
load with regard to VM pressure, you could do worse than simply stat
()'ing the files in /var/vm and basing your decision on how much swap
space is being used by the system.
The problem you will face by looking in task_info() is that these
structures can change every point release for Mac OS X, and if they
do, you'll end up basing your applications decisions on bad/stale
information.
-- Terry
--
Andy Pavlo
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden
