Hello, friends!
This text should clarify some questionable concepts implemented in CocoaTop, the ideas behind those concepts, and the idea behind the application itself. Also, it should be a fun read, at least for some ;)
Before we begin I would like to thank Luis Finke for making miniCode (available in Cydia) – a nice alternative to XCode that became an IDE for my first iOS app, which is also my first Objective C app. (Hey, if you think I typed the whole thing on the iPad, you're wrong. I even used Theos, goddamit, okay! But that's not the point!
Update: One of the most controversial topics concerning CocoaTop was the icon ;) . The original one, which I drew myself rather hastily, became the target of criticism on almost every forum or blog, not excluding Chinese, Korean, or some Hindu ones. That's when @DylanDuff3 kindly offered me his own version of the icon, which is used currently.
Now, you could say that the purpose of CocoaTop is to replace the original terminal 'top' – but it is not. First of all, the UNIX terminal is a thing in itself: every iPad user has to have a terminal installed, otherwise (s)he can be mistaken for a dork, or worse – a humanitarian. Also, 'top' executed on an iPad always attracts people's attention. So the idea behind CocoaTop is this: I wanted to create something nice, gaining knowledge in the process. If you find it useful, well, you're in luck!
While working on CocoaTop I found a book, a site, and a forum by a man named Jonathan Levin. I don't know how I managed to overlook this hilarious stuff. It gave me a great inspiration boost, not to mention loads of bad-quality source code to ponder on. Thanks to Jonathan's in-depth coverage of hidden and undocumented APIs this version of CocoaTop features real-time per-process network statistics! Also, if you're into console utilities & SSH, try his Process Explorer for iOS and Mac OS X.
Ok, on to the fun facts:
★ CPU usage sums up not to 100% but to cores×100%. Moreover, it can actually exceed this value, and it surely will when the cores are doing the real stuff: protein folding and shit like that. CPU exceeds 100% not for your amusement, but due to a scheduling policy of the Mach Kernel, which is called decay-usage scheduling. When a thread acquires CPU time, its priority is continually being depressed: this ensures short response times of interactive jobs, which do not always have a high initial priority, especially on weaker mobile platforms. The decayed CPU usage of a running thread increases in a linearly proportional fashion with CPU time obtained, and is periodically divided by the decay factor, which is a constant larger than one. Thus, the Mach CPU utilization of the process is a decaying average over up to a minute of previous (real) time. Since the time base over which this is computed varies (since processes may be very young) it is possible for the sum of all %CPU fields to exceed 100%. And this is why Android sucks. Also, because of Java, which isn't bad by itself, but... the mobile world?
Update: You may have noticed that on older versions of CocoaTop the kernel task (pid 0) took up a lot of %CPU, in fact it took up all unused CPU power. This is because for every CPU core there's a kernel thread which halts the core when it's not used to save battery life, effectively eating up remaining CPU cycles. You can actually find these threads when you switch to process details, thread mode: they will have a small 'i' for 'idle' in the state column. Newer versions of CocoaTop no longer include there threads in kernel CPU usage. Unfortunately, on 64-bit devices information on kernel threads is substantially limited.
★ Everyone knows about processes, but what about Mach tasks? These are actually different things. In fact, it is technically possible to create a Mach task without a BSD process. A Mach task can actually be created without threads and memory (ah, the benefits of The Microkernel, my love). Mach tasks do not have parent-child relationships, those are implemented at the BSD level. This implies that BSD (or, generally, POSIX) has more morale, but not really. In UNIX, it is actually the norm for the parent to outlive its children. Furthermore, a parent actually expects their children to die, otherwise they rise as zombies. This is why I love pure microkernels.
Update: A barebone task cannot be created in iOS usermode, because the corresponding API task_create() is removed. But the underlying kernel function task_create_internal() still exists and creates a task when a BSD process is launched.
★ You can kill processes by swiping to the left, but this seems cruel. One thing I would really prefer is killing zombies, but not sure if that fits with the iOS philosophy.
Update: Actually, a zombie is not a process, but rather just a kernel entry for a process which no longer exists. So you can't kill it. The only reason for keeping it is to remind a parent process of a child's previous existence and save any bits of data left over by the child, i.e. an exit code. When the parent process finally collects these data (or dies), the zombie disappears.
★ There's no such thing as a running process, because it is the threads that run, not processes. So why is there a 'Process running' state? Well, this is done to simplify the output, and actually taken from the original 'top' source code. Most process states are calculated from thread states using a simple rule of precedence: i.e. if at least one thread is running, the process state is presumed 'R', and so on. The complete list is provided in the column info: just tap (i) at the 'Process state' item while managing columns.
★ There is also a column called 'Mach Actual Threads Priority'. What it actually contains is the highest priority of a thread within the process. This is also the way original 'top' works. Also, there are several scheduling schemes supported by Mach, but only one of them is actually used in iOS – 'Time Sharing'. The other two, 'Round-Robin' and 'FIFO', will be marked in this column using prefixes R: and F: respectively, but I've never seen them. I added those marks out of curiosity - write me a letter.
Update: Round-robin scheduling is actually used for certain threads throughout the OS, especially kernel threads. In fact, all kernel threads default to the round-robin scheme: see for yourself! (If you're lucky to see kernel task details)
★ Apple tightens up security with each new version of iOS, so CocoaTop can no longer show details about task 0 (the kernel task) on iOS 8. You can still enjoy this data if you have iOS 7! Actually, the iOS could be considered the most secure public platform of all times, only if it wasn't so stuffed with backdoors, at least in v.7 ;) Anyway, it's better than the other non-evil company ;)
Update: It seems that details about the kernel task are available on some platforms, while absent on others. Maybe this depends on the jailbreak method used. I'm glad to inform you that this info is once more available on some devices running iOS 9!
★ There's a 'Mach Task Role' column which actually shows the assigned role for GUI apps, like in OS X. I've noticed this works only on iOS 8+.