There’s much bad press around about the Finder under Mac OS X. Probably the most common complaints about the Finder are in relation to either:

networking, or

previews, usually those in column views

The question many people ask is simply “Why is still still like this in Mac OS X today?”. This is, on the surface, a perfectly sensible question. After all, clearly Apple already knows about the problems: they use the Finder too, and plenty of people have complained about it over time. So what’s going on? Why hasn’t Apple fixed all this yet?

There have been threads like this on every Mac mailing list, forum or discussion board for the past few years, surely the Finder is at fault?

Just how much of this is actually the Finder’s fault?

While the initial thought of many people would be that it’s clearly all the Finder’s fault — the problem happens when they’re in the Finder, how could it not be the Finder’s fault? — it may not necessarily be so. Why? Well the two major areas of gripes aren’t actually handled primarily by the Finder.

Network Magic

Network communication in the Finder generally means a network mounted volume. These are handled in Mac OS X by “mounting” the server into the filesystem and that mount is generally handled by the kernel (possibly with a helper daemon to handle some of the task). This is a nifty trick as it means that files from the server are available as if they’re local files to any application without any special code to handle network code.

As with any nifty trick, it does have some drawbacks. The main drawback is a concept known as blocking. When a connection to a server is lost or gets slow, requests to read from that connection will do what is known as “blocking” inside the kernel. This means that the thread attempting to get information about that connection (say a listing of files on it) will be paused by the kernel and not scheduled to run again until the network operation either completes or times out. If this is the main thread of the application then the application may stop responding to events and the WindowServer will display the dreaded spinning wheel.

The Finder could in some cases prevent this particular problem from occuring by either requesting much of this information (some of it very basic) on a seperate thread thereby avoiding the main thread of the application being blocked. While this would solve much of the problem for network volumes, it may cause a slowdown in the Finder when used on local volumes as it passes requests off to another thread and back each time something needs to be done on the local disk. Solving this should also be fairly simple, if the Finder keeps track of the volume that it is currently exploring and if it is a locally attached volume or a network volume (or possibly a removable volume which may also be likely to disappear from under the kernel’s nose) and decide how to thread or not thread the request based on that.

Pretty Previews

When navigating in the Finder in Column view there’s a preview of the currently selected item displayed in the rightmost column. This is great as it can give a quick idea of what you’re looking at. On the other hand this can be awful if you’re looking at a multi-hundred-megabyte file that the Finder must read to display the contents of to show your preview. The problem here is pretty much the same problem that happens with networking, you click a file and bang the Finder pauses for a while to do whatever it is, shows a spinning wheel and eventually comes back and shows the preview.

But why?

When you click on a media file in the Finder, the Finder, like most Mac applications will defer to QuickTime to process the file and display a preview. This makes sense and is the right thing to do: after all QuickTime knows about a lot of different media formats so it should be able to display a preview of almost any media file we can throw at it. This provides great functionality for the user — they can see previews of all their great movies, pictures and whatnot — but it also presents a problem.

QuickTime is a very old piece of software. QuickTime 1.0 was released onto an unsuspecting world on December 2, 1991. In the time since then it has evolved remarkably into the entity we have today, but there is still some assumptions in it from that early code. Some of that includes the thread safety of various functions. What this means is that the Finder can’t always farm off some of the decoding and background work to another thread because QuickTime (at least in some cases) must run in the main thread.

What can Apple do about this? Well they’ve been working on it a long time and QuickTime 7.0 in Mac OS X 10.4 is a big step forward to QuickTime becoming more modern but sometimes, it still needs to run on the main thread and this is when the Finder in Tiger is most likely to do it’s little spinning wheel trick. It’s something that Apple is working on, but once again it’s not necessarily the Finder’s fault.

But How Much of This Has Already Been Done?

Of course this is all pure speculation and I’ve never seen the Finder code so I can’t tell if this will help in the slightest or not, but it’d be what I’d look at first if I were working on the Finder in this area. This situation has improved significantly in Mac OS X 10.4, so I wouldn’t be surprised if they’ve done at least some of this already.

The main take home lessons from today are:

I felt like ranting after reading that mailing list thread

Not everything can immediately be blamed on what you think it is

So let’s not always blame the Finder for what it’s doing, it may not be all its fault and you’ll just hurt it’s feelings.

This entry was posted
on Sunday, July 31st, 2005 at 11:52 pm and is filed under Mac.
You can follow any responses to this entry through the RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.