Process Manager Miscellanea:

A Selection of Process Manager Techniques, Gotchas, and Tidbits

by Bob Clark

July 1998

---

---

Table of Contents:

• structures
• routines
• how it works
• techniques
• hacks, bugs, and gotchas

---

The Process Manager documentation is on the web.

Peek-a-Boo is a process watcher that was written, in part, to learn about the Process Manager.

On the whole, a process is the same thing as an application. There might be some corner cases where a process isn't an application, but I can't remember them now. An application is always a process.

---

Structures

• A ProcessSerialNumber is an eight-byte structure for ID'ing processes. I've noticed that the high long seems to be zero, and the low long is incremented for each new process, starting at 8192.

  Why in the world they need eight bytes I'll never know. Some people accuse me of running a lot of processes simultaneously, but I've never needed more than eight bits. Eight bytes is enough room for 1.8 x 10¹⁹ processes!

• A ProcessInfoRec holds all kinds of information about each process.

---

Routines

• Getting PSN's
  • GetCurrentProcess
  • GetNextProcess
  • GetFrontProcess
• Getting Information
  • GetProcessInformation
• Comparing PSN's
  • SameProcess
• Doing Stuff
  • SetFrontProcess
  • WakeUpProcess

---

How It Works

(These are personal observations and should not be interpreted as anything Apple acknowledges, let alone supports.)

• Who gets the processor?

  As you probably know, process switches happen when WaitNextEvent is called. The Process Manager decides then if somebody else gets to use the processor for a bit.

  The frontmost process gets a shot at the processor, then the first background process waiting for it, then the frontmost process, then the second background process, then the frontmost, then the next background... and so on.

  What this implies is that the frontmost process will always get at least half of the chances to use the processor. (It's possible that none of the background processes want the processor; then the frontmost process gets the extra chances.)

  What this also implies is that if you have a dozen background processes, and they all want the processor (like if they've all used 0 as the sleep parameter in WaitNextEvent), then the Process Manager will only give each background process the processor once every 24 opportunities. Half of the chances go to the frontmost process, with all the waiting background processes round-robining.

  

---

Techniques

• CPU percentages:

  You may want to see what percentage of the CPU a specific process uses in some interval of time (say every second).

  In order to get the percentage of the processor that a process is using, compare the change in processLaunchDate with the change in TickCount():

  ( processLaunchDate₁ - processLaunchDate₀ ) ÷ ( ticks₁ - ticks₀ )

• Is a process background-only?

  processMode is all the flags from the 'SIZE' resource of the process. You can and it with modeOnlyBackground (0x00000400) to see if it's background-only. SetFrontProcess only works with processes that are not background-only.

---

Hacks, bugs, and gotchas

• Four-byte constants vs. eight-byte PSNs

  Several Process Manager constants are long's: kNoProcess, kSystemProcess, and kCurrentProcess. The documentation says these "can be used instead of a process serial number to identify a process." But a real ProcessSerialNumber is eight bytes. The documentation doesn't say to set the high long to zero.

  ProcessSerialNumber aPSN;

aPSN.highLongOfPSN = 0L;
aPSN.lowLongOfPSN = kCurrentProcess;


  Then you can use the PSN.

• processLaunchDate has a misleading name

  You might think that processLaunchDate is in the Mac's standard "number of seconds since 1904" format. But it's not. It's in ticks, not hh:mm:ss. So it can be mislead by two errors:

  • There are 60.15 ticks per second, not 60 ticks per second.

    We typically think of ticks as being 1/60 of a second. But it's actually a little bit off. This doesn't usually bother us, since it's only one fourth of one percent. But if we're trying to compute the time a process was launched, then that error can accumulate. In a day, it's more than 200 seconds.

  • TickCount() isn't updated when the computer is in MacsBug. So if you've spent much time in MacsBug, then the computed launch time (in hours, minutes, and seconds) will be screwed up.

  Peek-a-Boo has these problems. To keep them from being obvious, it only updates its computed launch time whenever the process list changes; this means that if you watch carefully when the process list changes, you can sometimes see the launched time field change.

• processActiveTime only updated on switches

  I've had it confirmed by DTS that a process's processActiveTime field is only updated when that process is switching out. Under most circumstances, that keeps it relatively up to date. But if you repeatedly poll processActiveTime without any process switches happening, you can poll forever and that field will never update.

  Perhaps the worst example of this behavior is if there's only one process running. Then the processActiveTime field is never updated!

  Peek-a-Boo has an ugly work-around to avoid this problem. We don't need to go into that here.

  OK. It detects if the total of delta active ticks is zero; if so, it assumes that it got 100% of the time in that interval.