A command in the TclX package.
Return the current POSIX process priority, or add priorityIncr to it if it is given (higher priority levels make the process less likely to be scheduled). Normal users cannot decrease the priority of their processes.
A Unix command that launches a program/process with a given priority in relation to other programs/processes. The idea is to make that program/process run slower than it usually does so as to use less CPU power and leave a more usable portion of it to other programs/processes that might be running at the same time.
-Kai- Technically, nice doesn't try to make a process run slower. It makes the scheduler more eager to take away its timeslices when there are other processes waiting to run. If your system is 100% idle, the process will still run at full speed. If the CPU is 80% utilized, the process will get the remaining 20%, plus a little extra. If the cpu is 100% used, the process tends to get a little CPU regardless. The higher the nice value you use, the greater this effect will be. On a 100% busy system, a process with nice=10 will get perhaps 20% of the CPU, while a process with nice=19 will barely have a pulse.
Now LES wonders if it's possible to do that with Tcl scripts in a cross-platform way.
From May 18 to this day of September, LES still wonders if it's possible to force a Tcl application to run slower and use less CPU in a cross-platform way...
AM (17 september 2004) Well, I just checked how this is to be done on Windows:
start /low tclsh.exe myprog.tcl
would put the process in the "idle" priority class (this is from the help information on start - do not ask me why there is no match between the keyword and the class name ;))
RS: "help start" tells me that there's these priority classes: low - belownormal - normal - abovenormal - high - realtime.
So, at start-up time it is quite possible: just define a small script that will start a new Tcl shell with the correct nice value from the start ...
If you want to do this dynamically, I suppose you could redefine the proc command to function as a small wrapper:
proc proc {arglist body} {
after $::timetowait
eval $body
}or something like that ...
Lars H: Don't you rather mean
rename proc tcl::original_proc
tcl::original_proc proc {name arglist body} {
namespace eval [uplevel 1 {namespace current}] [list ::tcl::original_proc $name $arglist "::after $::timetowait\n$body"]
}or something like that? Your suggestion just causes proc to evaluate the bodies immediately, it doesn't define any commands!
Not that I'm sure either one would do much good. Every procedure call would suddenly have an extra delay (that in itself can have a very uneven effect), but whether the time spent waiting can actually be used by other processes is very much dependent on how this waiting is implemented. In the simplistic implementation that after simply sits in a tight loop that polls the clock, other processes would not benefit from the proc redefinition.
AM Yes, you are right - I later realized that I had not thought enough about it. As for the waiting: it is my understanding that such waiting is usually implemented in such a way that other processes do get CPU cycles, but I am no expert in this field ...