In the last couple of months, I’ve gotten a lot of questions around multi-core support. Most of that has been around PixelBender, but there have also been questions around the rendering support added in 2007, and about ActionScript, which still runs on a single thread.

In a much belated continuation of my series “Why it works that way,” I wanted to share with you a quick question I was asking Flash Player engineering. The question was: “Why does ActionScript always run on the first core?” This was really getting at: “Why can’t we spread the love around and round-robin ActionScript to a different core based on how many Flash Players are running at once?”

I figured that if ActionScript were running on processor core A for one SWF and processor core B for the second SWF, the general performance of both SWFs would be better right? Well, it turns out I had a incorrect assumption here, and by clearing that up showed something interesting (at least to my naive self). It turns out that it isn’t always the first core. ActionScript runs on the same core as the HTML page that hosts it.

If you happen to have two pages, or two tabs running in different processes that happen to be running on different cores, the ActionScript will be running on different cores. While there isn’t much (anything) you can do to get people to run Flash instances on different processors, I found the reason for why it runs on the same processor as the browser is both interesting and sort of “duh” at the same time.

The reason for both the browser and Flash Player running on the same processor is to specifically keep ActionScript synchronized with the page. This allows for the SWF and the page to interact through ExternalInterface. By having the two systems on the same core you won’t run into lots of strange errors where an application that relies on both AS and JS works one time, but not the next on the same machine because a slight difference in timing.