The adventurous techie student...

A blog describing computer internals and electronics, from a student's viewpoint

"Paperbacks"

Monday, July 12, 2010

Multi-process software: boon or bane?

If ever you've used Google Chrome, you'll notice that if it has multiple tabs, multiple copies of the executable (chrome.exe under Windows) will show up in the operating system's process manager (Task Manager under Windows), even though there is only one window open. How does this happen, I'll write later. For now, let's focus on its strengths and weaknesses.

Before I proceed, some terminology round-up:
  • Process - a running instance of a program / executable file
  • Thread - A function running as a "mini" process within a normal process
  • Mutex - An object used by operating systems to ensure exclusive access to a resource, such as memory and CPU time
  • Context switch - The process of telling the CPU to execute/resume execution of another function
One of the good points of the multi-process concept is that a crash in one process does not affect other processes, thereby making the system more stable and resistant to software bugs that are sufficiently fatal to bring down a computer (bluescreen in Windows, kernel panic in Linux/Unix.). This is in contrast with threaded software, where a crash in one thread will cause all other threads in a process to be killed as well without an opportunity to clean up, thereby leaving dangling objects like mutexes which can choke up other processes and cause system crashes. Also, multi-process software can be designed so that each copy of itself may run as a different user with the same, greater, or less privileges, compared to threaded software where each thread is tied to the privileges of its container.

With the good comes the bad. Processes require more resources like memory to maintain, and it is costlier to do context switches between processes than between threads, since a process context switch involves saving/restoring more data than thread context switching; that's why it is easier to run out of memory with multi-process applications. This consideration especially applies with embedded-system operating systems, such as those found in the iPhone and iPad. Another disadvantage is that, implementation-wise, a multi-process executable is harder to code.

So, is this concept good or bad? The answer is that it depends on the program's purpose. For Web browsers, this is good, because, from a security standpoint, you have no control over the code in the Web pages served to you; it may be containing malware. For games, the very nature of its coding makes it impossible to spawn (branch out) its operations across multiple copies of itself, since process switches are not deterministic.

Sunday, July 11, 2010

So nice user interfaces are better...

...but not if it restricts you too much. Besides, a nice user interface (UI) for a badly-written piece of software is useless and vice-versa; although the former is worse than the latter, the latter is more pronounced in the use of normal software.

The Ribbon UI that comes with Microsoft Office 2007 and beyond has become very "popular" to people. I place the word "popular" in quotes because, in reality, it is quite misleading, and many companies who use this UI design in their programs do so without first seeing how many features their programs have, and what their programs do; as a result, it's the end-users who suffer digging through tabs just to find the features they really need.

On one hand, it does a good job of placing the most frequently-used items at the front and in "big" size, while less-used items appear in smaller icons or in their dialog boxes; on the other hand, it will be a pain for the user who is accustomed to the classic design of toolbars and menus; such a user will have to find which category a particular command falls under, and it is not a suitable UI paradigm if your program does not contain a ton-load of features, or if keyboard shortcuts are an extensive requirement, such as in programs for troubleshooting programmable-logic controllers.

It may be apparent that the UI design of the Ribbon was overly emphasized for novice users; in fact, the MS Office user base has more people very proficient at it (the old ones with menus, that is) than novice users; hence, widespread backlash ensued on the new UI of MS Office. Besides, the glow on the Ribbon and its large icons are a no-no for graphics editing and computers with a limited color palette - say, 16bpp or low screen resolution.

Anyway, in any case, whether a program's UI will live on or die off is a matter of personal opinion and preference.

Sites: