· PIDs
  · drawbacks
  · v0.1
  · todo
  · download


make.pl Opera utilities
On a multiprocessing system other processes, which don't currently have your attention, may still bog down the system.  Many windows are quite active (behind the scenes), while doing nothing useful: adware, javascripts in browsers, windoze emulators...  This can make especially slower PCs sluggish when many windows are open.  There are two things one could do about this:
  • Different priorities: You could dynamically assign different priorities, highest for the processes associated to the focused window, next highest for other visible windows, somewhat lower for occluded windows or those on other viewports and lowest for iconified ones or those on other workspaces.  Alas Unix allows you to lower the priority at will, but only a process with root permissions could bring them back up.
  • Stopping and continuing: Sort of an extreme case of the previous, where processes either run or don't at all.  Quite a few programs painlessly (or almost) support a STOP signal, completely turning them off temporarily and a CONT signal at a much later time.  At least on XFree86 the server connection doesn't time out.

If you stop the right ones, the overall speed of your PC increases noticeably. "Top" can give you a good indication of which processes those are.  The speed when getting big processes back may hurt a little, because they may have been completely swapped out after a while.  But it's still faster than starting them from scratch.

You can let the stopping and awakening of processes occur based on workspace switching.  Any auto-stoppable window that does not appear on the current workspace is then stopped.  When you get back to its workspace it gets awakened again.

If instead you use viewports that is also possible.  Any auto-stoppable window that does not appear on the current viewport is stopped.  If you use both workspace and viewports in combination, you may set both.  But maybe, like I do, you've got the browser and mailer on different viewports of your internet workspace and communicate between them frequently.  Then you should choose only workspace based stopping.

Determining the PIDs

Traditionally X11 is weak for mapping windows to system processes responsible for them.  There is an X-window property _NET_WM_PID for this, but few application set it yet.  And when they do, it may represent the process or thread responsible for the GUI, not the one that's wasting CPU.  The following mechanism is applied here:
  • If the window has a (sawfish) property pids, which is a list of numbers, those are the pids.
  • If that property holds a string, it is a regexp matched against the output of auto-stop-ps-command.  This is best set through matched windows in the GUI.  When this gets called, all windows having a regexp that matches at least one line of output are processed at once.
  • If that property holds a function, it is called and should return a list of numbers (1 at least).
  • If none of the above apply, the X-window property _NET_WM_PID is checked.
  • If that doesn't exist, you are prompted for one or more space separated numbers.
  • In all cases, the numbers are stored in property pids for future access.


  • Stopped windows holding the X selection can not honour requests for it, blocking the requesting window till it times out.
  • Component mechanisms like KDE's dcop or Gnome's bonobo will fail if the targeted window is stopped.
  • Stopped windows running some protocol with a keep alive element to another server, may time out.

Version 0.1 (2002-11-30)

Initial release.


  • Also optionally auto-stop when shaded or iconified.
  • Stop only after a timeout to let the program finish some task.


turbo-X11-0.1.tgz (2kB)
(Last modified 2002-12-03)