mirror of
https://git.FreeBSD.org/ports.git
synced 2024-10-31 21:57:12 +00:00
79 lines
2.9 KiB
Plaintext
79 lines
2.9 KiB
Plaintext
|
getrusage
|
||
|
|
|
||
|
|
For a detailed description about the values returned by
|
||
|
|
getrusage() please consult your usual C programming
|
||
|
|
documentation about getrusage() and also the header file
|
||
|
|
sys/resource.h. The $ru_who argument is either
|
||
|
|
RUSAGE_SELF (the current process) or RUSAGE_CHILDREN (all
|
||
|
|
the child processes of the current process). On some
|
||
|
|
(very few) systems (those supporting both getrusage() and
|
||
|
|
the POSIX threads) there is also RUSAGE_THREAD. The
|
||
|
|
BSD::Resource supports the _THREAD flag if it is present
|
||
|
|
but understands nothing about the POSIX threads
|
||
|
|
themselves.
|
||
|
|
|
||
|
|
Note 1: officially HP-UX 9 does not support getrusage() at
|
||
|
|
all but for the time being, it does seem to.
|
||
|
|
|
||
|
|
Note 2: Solaris claims in sys/rusage.h that the ixrss and
|
||
|
|
the isrss fields are always zero.
|
||
|
|
|
||
|
|
getrlimit
|
||
|
|
|
||
|
|
Processes have soft and hard resource limits. At soft
|
||
|
|
limit they receive a signal (XCPU or XFSZ, normally) they
|
||
|
|
can trap and handle and at hard limit they will be
|
||
|
|
ruthlessly killed by the KILL signal. The $resource
|
||
|
|
argument can be one of
|
||
|
|
|
||
|
|
RLIMIT_CPU RLIMIT_FSIZE
|
||
|
|
RLIMIT_DATA RLIMIT_STACK RLIMIT_CORE RLIMIT_RSS
|
||
|
|
RLIMIT_NOFILE RLIMIT_OPEN_MAX
|
||
|
|
RLIMIT_AS RLIMIT_VMEM
|
||
|
|
|
||
|
|
The last two pairs (NO_FILE, OPEN_MAX) and (AS, VMEM) mean
|
||
|
|
the same, the former being the BSD names and the latter
|
||
|
|
SVR4 names. Two meta-resource-symbols might exist
|
||
|
|
|
||
|
|
RLIM_NLIMITS
|
||
|
|
RLIM_INFINITY
|
||
|
|
|
||
|
|
NLIMITS being the number of possible (but not necessarily
|
||
|
|
fully supported) resource limits, INFINITY being useful in
|
||
|
|
setrlimit().
|
||
|
|
|
||
|
|
NOTE: the level of 'support' for a resource varies. Not
|
||
|
|
all the systems
|
||
|
|
|
||
|
|
a) even recognise all those limits
|
||
|
|
b) really track the consumption of a resource
|
||
|
|
c) care (send those signals) if a resource limit get exceeded
|
||
|
|
|
||
|
|
Again, please consult your usual C programming
|
||
|
|
documentation.
|
||
|
|
|
||
|
|
One notable exception: officially HP-UX 9 does not support
|
||
|
|
getrlimit() at all but for the time being, it does seem
|
||
|
|
to.
|
||
|
|
|
||
|
|
getpriority
|
||
|
|
|
||
|
|
The priorities returned by getpriority() are
|
||
|
|
[PRIO_MIN,PRIO_MAX]. The $which argument can be any of
|
||
|
|
PRIO_PROCESS (a process) PRIO_USER (a user), or PRIO_PGRP
|
||
|
|
(a process group). The $pr_who argument tells which
|
||
|
|
process/user/process group, 0 signifying the current one.
|
||
|
|
|
||
|
|
setrlimit
|
||
|
|
|
||
|
|
A normal user process can only lower its resource limits.
|
||
|
|
Soft or hard limit RLIM_INFINITY means as much as
|
||
|
|
possible, the real limits are normally buried inside the
|
||
|
|
kernel.
|
||
|
|
|
||
|
|
setpriority
|
||
|
|
|
||
|
|
The priorities handled by setpriority() are
|
||
|
|
[PRIO_MIN,PRIO_MAX]. A normal user process can only lower
|
||
|
|
its priority (make it more positive).
|