Threading rears its ugly head, again

It seems to be a recurring topic here on my blog, threading. I was asked to look at a problem for a client yesterday and discovered a very subtle threading issuing (I actually didn't create it, one of the other people on the project created the problem when he added some code). Basically in order to show progress while the app is doing stuff, some code is executed on a separate thread. However, the main thread basically spins in a loop using something like:

while (threadRunning)
{
	NSDate *newDate = [[NSDate alloc] initWithTimeIntervalSinceNow:0.05];
	[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:newDate];
	[newDate release];
}

The application uses CoreData for managing data and the second thread accesses the CoreData store. You would think that the above code blocks the main thread from doing anything while the second thread is running, but like my issue with NSTask, the main thread is actually doing something. In this case, the UI is bound using Cocoa bindings to the managed object context and the secondary thread was also using the same managed object context. As explained in Apple's docs on Core Data multi-threading, you could get a deadlock when 2 threads are accessing the same managed object context at the same time. Bindings hid the fact that they were talking to the managed object context. I should have realized this, but I didn't.

Will I ever learn about how to get threading right?

Are software bundle deals just marketing hype?

I've commented on the past about MacHeist bundles and eventually decided that the bundles are not a bad thing with the exception of potentially decreasing the value of individual pieces of software. Last week, MacUpdate Promo started a new bundle deal with some interesting apps and Parallels being offered up if certain sales goals are reached. That's fine. Even though I have Parallels and Hazel, I bit as some of the other pieces looked interested and I like collecting software (odd hobby, I know). Typinator and MenuCalendarClock are already in use daily.

So now I come to my point on this entry. The MUPromo site indicates that X units have to be purchased to "unlock" Parallels. However, over on several other websites, they're running the ad that appears to the right. If you saw that ad, you would expect to get Parallels and 9 other apps as indicated. So, unless MacUpdate wants to be accused of false advertising, Parallels and the other 9 apps listed on their site will be included. Why the whole charade over unlocking based on sales numbers? Just hand over the applications and be done with it. So, in actuality, I should have all 10 applications today as indicated in the ad, but I have to wait until MUPromo decides that it is going to "unlock" all the apps.

(No one has asked me to be part of a bundle for ReceiptWallet and after this post, I'm not sure anyone will :-)).

Hacked Serial Numbers

In the past, I've written about software piracy, registration codes and catching users with pirated serial numbers. As part of the latest update to ReceiptWallet, I added some additional checks for invalid registration codes (read, pirated or hacked). One of the simplest ways to deal with this would be to have ReceiptWallet check in with my server to validate the code, but I don't like that idea. What happens if my server goes down or my company goes away? Users can no longer use the software, so I avoid that method. This morning, after I released a new version of ReceiptWallet, one of the first messages I received was a user saying that there was an error with his serial number. This meant one of two things; the user was given a refund and is no longer eligible to use the software or he used a hacked serial number. After a little probing, he admitted that he didn't remember purchasing the software and wanted to know how to buy it. I didn't outright accuse him of using a hacked serial number, but I suspect he figured it out pretty quickly.

As with most serial number schemes, there is going to be no way to stop those that are serious about pirating. I have no plans on spending a ton of time on thwarting pirates, but an enhancement here and there doesn't hurt.

I wonder how many other email messages I'll get about invalid serial numbers.

Librarians of the future (or is it now current?)

Sometime between 1995 and 1998 (I can't remember when), I went with my parents to a public meeting about a new main library. At that time, I thought it was a waste to have a huge main library as a majority of the city lives nowhere near downtown. While there are now more people living in downtown, the focus, in my opinion, should be to improve the branch libraries that will benefit many more people. All these years later, I still believe the same thing; spending millions of dollars on something that most people won't use is a waste. How about increasing the hours that the branch libraries are open instead of a main library? Oh and the new main library still isn't built; projected completion is 2011.

In any case, that's not what this entry is about. Way back then, I told my parents that I thought the librarians of the future would be professional web surfers. While anyone can search for information, a professional is needed to:

• Use appropriate keywords to quickly find relevant information.
• Ascertain which results are from reputable sources (someone's post on a forum is unlikely to be considered as an appropriate source for facts).
• Distill the potentially large number of search results into a usable form.

In some cases traditional librarians are still needed, such as the case for children's librarians, but research librarians seem like they should deal with completely electronics resources as that is the most efficient way to find information (if you know where to look).