This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Working with the VW process monitor Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

When you first fire it up (last item on the Debug menu of the launcher), you'll see a list of user processes. Right off, you'll notice that any open workspaces are running in their own process - this is an aspect of the MPUI (multi-process UI) that was introduced in VW 7.1. The bottom line on that is that there is no longer a singular (distinguished) UI process - so a process spawned from a workspace during experimental development won't hose down the whole UI.

Pull down the View menu in the process monitor - there are three options:

• Show all
• Show Userr (meaning, all ST processes launched via your actions)
• Show System (housekeeping stuff)

Switch to the system view - you'll see the idle loop process, the Low Space process, and a bunch of other things. You'll note that these processes are mostly at very high priorities - and that most of them are blocked most of the time. This explains how your system can become unresponsive if you get into a thrashing GC loop - the Low Space process is running at a priority of 91! If you get stuck in that, it's very hard to break out. If you see that happening, you might want to look at my memory management posts [here and here and here).

Now go back to the user view, and pull down the Process menu. Everything will be grayed out - because you haven't selected anything. So go ahead - select a workspace process and pull the menu again. You'll now see that only the proceed menu pick is disabled - because the process you have selected is, in fact, running. Go ahead an select Debug - bam, you get a debugger on that process. Go look at the process monitor - you'll see that the state is now suspended. Go ahead and hit the run button in the debugger, and notice that the state changes back.

This is very useful stuff. Say you have a background process in an application you are testing - and you suspect that the process is having a problem. Previously, it was fairly difficult to get into that process and figure out what was happening - now it's simple. Just select the process in the monitor, and either debug it or terminate it (depending on whatt your needs are). This can still be hard if your process becomes CPU bound and is running at a high priority, but it's a highly useful feature - I've made extensive use of it in BottomFeeder development.

Another nice thing you can do is use the dump option. That will dump the current execution stack for the selected process to a file. With a little work on your part, you could easily include this capability in an end user application as a diagnostic tool. The View option does almost the same thing, but dumps to a window instead of to a file.

The last thing to look at is the sample time - by default, every 2 seconds the monitor looks at the current state of running processes. You can increase or decrease the frequency.

All in all, the process monitor is a very useful tool - if you haven't been using it, make sure that you take a look