[...]
I'll give you two re-world examples from two (closed source, but
still) apps we develop at my current employer.
The first one is a server/network monitoring app where there are lots of
child processes devoted to performing checks, storing data, displaying
results etc. Most of these processes just run at the default nice level.
One of the processes sometimes has a need for a cryptographic key pair and
it can generate this when it needs it, but it's better if one is reaily
available, so we have a seperate child process running that maintains a
small pool of new key pairs - this process runs at a high nice level since
it should not take CPU time away from the rest of the processes (it's not
important, it's just a small optimization), the need for key pairs comes
at large intervals, so the pool will almost never be depleted even if
this process doesn't get very much CPU time for a long time and besides,
if the pool ever gets depleted its no disaster since the consumer will
then just generate a key pair when needed and burn the required CPU.
The second is a backup aplication where one child process is in charge of
doing background disk scanning, compression and encryption. This process
is not interactive, it must result in minimal interference with whatever
the user is currently using the machine for as his primary task and
time-to-completion is not really that important. So, this process runs at
a rather high nice level to avoid stealing CPU from the users primary
task(s).
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
--
