One of the rules of Macintosh programming is that if you are ever busy (ie not responding to user events) for a significant amount of time, you should put up a busy cursor, like the one shown below. The reason for this rule is fairly obvious and in general applications obey it quite well.
However the Mac OS is not a real time system, and it can be very tricky to predict how long certain operations are going to take. For example, operations that you think should be quick (like drawing a glyph) can take a very long time (if for example the font containing the glyph is in a suitcase on AppleShare volume mounted via Apple Remote Access). So just putting up the watch cursor when you begin a long operation is not enough. You need to have a real time task (a VBL task for example) that determines if your application is handling events and, if it isn't, puts up the watch cursor.
The program that illustrates this best is, of course, the Finder.
Do not take this to mean that I advocate that cursor spinning should be done from a VBL. Your code should still include calls to manually animate the cursor as it's making progress. Animating the cursor only from a VBL is evil because it's possible for the code to be making no progress (ie it's crashed) while the cursor is still showing progress. The busy cursor VBL should only come into play when something takes an unexpectedly long time to complete.