nullstream weblog - Thread Abuse

« Fire from a can of coke and a chocolate bar | Trade-up to WinXp-64 »

Thread Abuse

April 25, 2005 01:55 AM PST


I do not understand why programs that are not massively IO or Disk bound require 44 freaking threads to run. Valve, I'm looking at you:


MSN Messenger weighs in at a svelt 12 threads, and I'm not even showing its window or in a conversation! Firefox and iPodService: what are you thread spankers doing? winlogon.exe, your engineers are shite.

Coming from GoAhead, I'm pretty used to multi-threaded coding. But the above examples are just ridiculous. There can be no explanation except programmer incompetence or laziness. I like threads, they're pretty useful for GUI based applications. But sometimes, threads are for people who can't program state machines.

Comments (6)
John, April 25, 2005 11:00 AM:

Hey you linked to GA, nice of you to help increase their page rank.
Yeah, what the heck it Steam doing?
Give winlogon.exe a break man, its a busy dude. It has notifications, callbacks and security stuff to deal with etc.
If you want to try something fun, use sysInternal's process explorer to see what all those threads in Steam are doing. You can see the function they are sitting in as well as their current call stack.
As for Alan's quote, he he very funny. In his case I'm sure it was made before the OS's he was using even had threads (certainly not proper threads), no it was probably defensive. In his case the quote might have been read, "massive state machines and zillions of processes are for people who can't program threads."
Seriously though any discussion about thread vs. process performance and overhead must take into account the OS and thread implementation being used.

Paul, April 25, 2005 11:10 AM:

True. Unix processes tend to be very cheap to create compared to Windows, so you typically see Windows programs using more threads. I also find the Windows threading APIs easier to use than pthreads. I think that one other thing that explains the high thread counts is COM. MSN Messenger probably uses a bunch of COM dlls that run their own threads so the programmer couldn't change that even if they wanted. Not sure what Firefox thinks it's doing, though.

The thing with Steam is that it wasn't even doing anything! It was sitting in the system tray at the time. And, it's not like Half-Life 2 or Steam is fast starting up! Maybe they think that if they use up all the system's threads, you won't be able to play other games.

Paul, April 25, 2005 11:19 AM:

I figured out what Firefox is doing, it subclassed ThreadPool:

class CityWorkerThreadPool : public ThreadPool {

This is where you create 20 threads, with one thread doing all the work, and the other threads wake up periodically to check to see if the first one is done yet.

John, April 25, 2005 11:22 AM:

Yep, processes are very expensive on Windows. The other thing is that Unix and Windows have very different programming models and approaches in practice. Not that they have to it just happens to be that way. I read a good article on that topic once, I'll see if I can find it.

I wasn't going to bring up the COM and system call stuff, but in many cases that is what is going on. You are using a feature in the system framework and it hooks in all kinds of stuff and starts threads etc. These treads are just waiting out for events etc. It beats polling though.

John, April 25, 2005 11:27 AM:

"CityWorkerThreadPool", nice. It could also be:
"TechJobWorkerThreadPool", where one thread actually does the work, while it takes one thread for each other related task like:
researching the work
specing the work
scheduling the work
crunching the schedule until it is unrealistic
assigning the work
checking to see if the work is done
assigning blame for why the work is late
and so on.

Paul, April 25, 2005 12:39 PM:

Also, "Schedule company Christmas party" and "decorate cube".

All links will be marked with the nofollow tag, making them useless for search rankings. Any posts containing spam URLs will then be deleted.