Shane Conder's Whateveritis of Nothing

So, after reading through perlipc about how threads used to be only available for emulating fork on Windows, I became curious to know if Perl, specifically ActiveState's ActivePerl, had it's own thread manager or if it used OS based threads.

Even when reading about threads it sounded as if they may not be true OS level threads since they were called "interpreter threads."  That sounded like something where Perl might have it's own manager.  In fact, Perl might be required to have it's own manager on systems where OS level threads do not exist.

On a typical Linux system, doing a fork will usually show the process duplicated in the ps view.  On Windows, however, I noticed that there was still only one Perl process running.  So, I went about to find a tool to show the threads of a process.

A quick Google search (or is that just "google" these days?) turned up PrcView (or pv on the command line).  So, I brought up the CPAN module at the command line (e.g. "perl -MCPAN -e shell") and checked it out.  Sure enough, there was only one thread sitting in the process.

Then I brought up my little test app that does two forks.  It ended up with 4 threads total in the process, which was great to see.  Why?

Well, if an application doesn't use OS level threads then the OS just thinks of it as a single process.  The reason this matters is because then all of the processing will only ever be scheduled on to a single CPU.  This used to only matter for servers and higher end workstations where most people would be running applications designed for a multiprocessor environment.  However, in the days of multicore chips and even hyperthreaded chips, almost anyone can have a system with multiple execution cores.  Any application that does spread it's processing across multiple OS based threads will benefit from this.  I'm not just referring to the performance of the application, either.  The response time and smoothness will be improved. 

Of course, since threads will truly be running at the same time, proper synchronization is that much more important. Even the Perl documentation talks about lower level calls not being re-entrant. 

At a first glance of Apple iTunes, one would almost certainly peg it as not using OS based threads.  After all, if you're downloading, or doing certain other tasks, the UI becomes completely non-responsive.  You can alt-tab in and out of it, but you can't actually do anything with it.  However, using this tool on iTunes right now, shows that it's using at least 17 threads.  So, the real question then, is what the *bleep* are they doing to cause the responsiveness and performance to be so poor??

Posted by Shane on February 9, 2007 8:42 AM | Permalink