I figured I would give a quick update on multithreading in Flash, as since I wrote about the subject last year, around 80% of the search engine traffic coming to my site are using keywords “multithreading in Flash”, “concurrency in Flash”, “threads in Flash” and literally hundreds of other variations. If you follow the latest Flash news then some of this might be old news, but I figured I would summarize it and then make some guesses about the future.
What will the API look like?
So earlier this year at Flash Camp Brazil, Arno Gourdol from Adobe had a future of Flash presentation. He covered quite a few things including what the concurrency API likely would look like. Here is the slides for that presentation (PDF) and bellow is the code sample found in that presentation:
myWorker.addEventListener(WorkerExitEvent.WORKER_EXIT, function(e:WorkerExitEvent) { trace("worker finished") });
myWorker.load({myMessage: "world"});
myworker.swf
[Entrypoint]
class MyWorkerDef {
trace("Hello " + Worker.parameters.myMessage);
Worker.parameters.myConnection.call("talkback", null, "all fine on the worker front");
};
var myWorker:Worker = new Worker(MyWorkerDef);
var c:WorkerConnection = new WorkerConnection();
c.client = { talkback: function(message) { trace("worker said: " + message) }
myWorker.load({myMessage: "world", myConnection: c});
Note this is not finalized and could change but for now it’s basically the Web Workers API from JavaScript.
The presentation notes mention that this will allow developers to leverage multi-core CPUs, you can have multiple workers at the same time and it is a shared-nothing isolation model.
Also note that Adobe has also been working on putting other Flash processes on a separate thread. Example they put bitmap decoding on a separate thread. This was added to Adobe AIR in version 2.6 and added to the Flash Player in the 10.3 update.
What do developers think of this?
There’s been some interesting discussion on whether this is adequate enough for developers here on bugs.adobe.com (if you haven’t already please vote for that feature request). Joa Ebert in particular has some interesting comments. I agree with these and other comments that a low level API is still need, but this current solution is enough to solve the most common problems of UI locking in Flash. However, with Molehill/Stage3D coming in Flash Player 11, we are likely going to see a lot more complicated 3D games that could use a better system later down the road.
When?
So concurrency is finally coming to Flash!! The next question big question is when is this happen? Many including myself though it would be in Flash Player 11, but unfortunately this worker API is not in the Flash Player 11 beta currently out.
I asked Thibault Imbert, the Product Manager for the Adobe Flash Runtimes about this on Twitter and he confirmed that worker threads would not be coming to Flash Player in version 11.0.
Which is unfortunately to hear after waiting for this feature such a long time. Now this doesn’t mean we are going to have to wait for Flash Player 12 for this feature. As Adobe also announced earlier this year is Flash is now on a quarterly release schedule. Which is why we have seen new features in minor updates of Flash with 10.2 then a 10.3. Flash Player 11 is likely to be released by the end of this year but we should be getting a Flash Player 11.1, 11.2, etc. with new features each time before we hit another big upgrade with Flash Player 12.
So how close is this API from being released in a future version of Flash Player? Close enough that there is a session at Adobe’s MAX conference in October 2011, called “Concurrency in Flash Runtimes“. So I would guess it will be available with Flash Player 11.1, possibly 11.2 at the latest. Either way, we should find out a lot more information after Adobe MAX.
Either way, concurrency is coming to Flash, it’s just taking a long time to get here.
Hi Matthew,
Nice article. There is definitely big interest in this feature.
Please, make sure you attend the session at Max about Concurrency, we will give a lot more details about the current design, which has changed a bit. If you cannot attend, of course the session will be recorded.
We would have loved having this in FP11/AIR 3, given that for games, it is also super useful to use with Stage3D, but we want to get the design right and it was too short to make it for FP11/AIR3.
You will also be able to inject bytecode to the ActionScript worker, you do not have to use a SWF (you will be able to) but most people may just want to inject bytecode generated by ASC or dynamically generated bytecode from as3commons for instance.
Of course tooling will make the workflow easy, so that you do not have to manually generate the ABC and link it yourself. So it will be pretty flexible.
We are also working hard for having maybe some objects you wil be able to share like BitmapData and ByteArray, which would be pretty convenient, for a lots of use cases.
Again, we decided to do this for the first phase of the Concurrency effort in Flash to solve, the UI locking issue (sometimes referred as reactive programming). Lower level access or even language support for Concurrency will come later. We want to introduce first, a safe way to leverage Concurrency which should solve most of the use cases.
After this, we will surely have a Concurrency 2.0 effort
Hope this sheds some more light!
Thibault
Product Manager | Flash Runtime | Adobe
Thanks for the feedback Thibault. It’s so awesome how available you are online and willing to answer questions and give a peak into what is coming up.
I unfortunately, won’t be able to make it to MAX. It’s a bit of an expensive trip from Toronto. I hope to go one year, but not this year. However, I will definitely be following any tweets and blog posts about session until it’s finally made online.
Also it’s great to hear that this is Concurrency 2.0 and it will continue to improve later. Still, it’s a great start and I think will be helpful for those coming from JavaScript to quickly pick up.
Thanks again!
WebWorker is a bad idea, the risk is that Flash will be slow.
Can you see all the people that don’t know how onFrame works misusing this.
Vic, not adding something to Flash because beginners or designers who don’t know how to code will misuse it, in my opinion is bad reasoning. As that’s an excuse to not add almost anything too complex that advances the Flash platform.
More likely, I imagine these type of users are simply not going to use workers, as they won’t understand it.
That said, Adobe seems to be working hard on making sure this is safe for so called “scripters” (beginner level coders). That seems to be one of the reasons for the delay, as Thibault mentions above wanting to really get it right.
I’m registered for that session and will definitely be attending and taking notes.