Mourning The Loss of Threading

I've used many different platforms. Through the years, I've gravitated towards systems with native threaded UIs. OS/2, for instance, had a threading system that led to accidental threading. The original idea behind COCOA on Mac OS X was to have one UI thread and one worker thread per app. Java UI is easily threaded.

However, many of these systems now run apps with no threading at all in them, leading to unresponsive UI elements. The user has no idea why the app is unresponsive; they're just upset about it and will stuff the click buffer full of clicks about it, which will have unintended consequences when control returns to the UI element.

Of all of them, I think I like Apple's automatic creation of worker threads. It removes the threading issue from the developer's mind. The developer is free to develop while the OS manages the creation and removal of threads.

I guess this approach is too 'hard' because it seems Apple has largely abandoned it, going with the standard one thread (process) per app, which has led to a less responsive UI. Before, when a given app was hard at work, its UI thread was still responsive, meaning you could click on things and so on. The 'work' was in a worker thread. Since this happens as a result of the OS' UI layer calling the app's action delegate in a separate thread created by the UI layer for this purpose. Since OS X uses Objective C, which does message passing by default, synchronization is something that can happen at the framework level, making things much easier on the developer.

However, there seems to be a tendency to ignore the idea of threading. Synchronization issues kind of suck. Developers have to maintain re-entrant discipline and need to code in such a way as to avoid deadlocks and data corruption. Discipline is often in short supply as development managers feel the need to push software out on short schedules, meaning they need to simplify their development, which is one reason threading is ignored. Threaded code has a different set of testing requirements, for instance.

However, if, as is done in OS X, the threading is a simple split between the UI layer and the app, managed by the OS, the majority of the issues can be tested for by the OS developer. This means Apple has to increase their testing, but it also means all Apple apps look lots more performant by default than comparable code on other systems.

Ok, Why Did I Pay $1500 For This?

I found a solution that has worked for a bit now for the Macbook headphone jack red led of death problem, where the internal speakers quit working after headphones are removed: take a q-tip and remove some of the cotton from the tip, trying to make sure there are not lots of wisps left around. Push the q-tip into the headphone jack. If it takes too much work, remove more cotton. Try to keep the cotton removal equal along the length of the q-tip because what you're trying to clean is waaaay back up in the jack. Once the q-tip is in there, twist it around, move it in and out and then remove it. If sound does not start up immediately, repeat the process. If sound still does not start, put a pair of headphones in the jack and remove them. If it still does not start, I guess you're not as lucky as I was. Btw, the q-tip came out really, really disgusting. Apparently that jack gets pretty dirty, and dirt was clogging the microswitch. Why it would work sometimes and not others and suddenly switch off all by itself remains a mystery, but, for now, it's working.