Why doesn't Flex support threads?

Question

Why doesn't Flex/ActionScript currently support threading?

Answer 1

To keep the barrier to entry low, since threads often result in more headaches than usefulness for beginner programmers. Flash is often used by people who simply wanted the WOW factor, and so adobe probably took the political decision to minimize the amount of support they would have to provide.

Ideally, they would support futures/promises (which I discovered by reading about the Io language), basically, asynchronous functions. As RJ Owen mentioned, something like web workers to run in background threads and not block the ui thread would be ideal.

But really at the low level, this is potentially hard for Adobe to do, because the execution model is tightly coupled to the graphics capabilities. From a basic understanding of the architecture, the flash player vm only reads precompiled bytecodes, running in the single threaded model, so adobe would have to radically change something for this to work.

Answer 2

Flash and Flex are based on Actionscript, which does not support threading. Adobe's official reasoning for this is that threads can cause very different behavior on different user machines, and race conditions in threading can lead to performance problems on an already performance intense platform like the flash player.

There is talk of supporting worker group pools similar to those in HTML5 in a future release of Flash, but this is not official yet.

For information on how to fake threading in Actionscript, check out Huen Tue Dao's presentation on greenthreads: http://www.slideshare.net/queencodemonkey/360flex-greenthreading-in-flex

Another alternative is to send numerically intense computations to Pixel Bender. Pixel Bender is a flash service that runs on its own thread, providing better performance. For more information on implementing this technique, check out: http://www.adobe.com/devnet/flex/articles/flashbuilder4_pixelbender.html

Answer 3

Why? Because concurrency is dangerous. Threads are a necessary evil. And they're often misused and overused. Instead of optimizing an algorithm, it is parallelized, although the parallelized version actually requires 10 times the resources than the single threaded, which in turn requires 10 times the resources the optimum would.

FlashPlayer has been designed for a specific set of tasks and creating content for the Flash Platform is so easy, that it's simply a good decision, that there is no risk an SWF will totally exhaust all your cores.

In the end, it is a political decision, and I am actually fairly happy with it. The FlashPlayer has a dead simple execution and rendering model, can't run into deadlocks or race conditions and can only block one core. This is just about like the decision, that any call must end after 60 seconds. I've seen a lot of people ask why. Well, because people like me dislike the idea of a GUI freezing for more than a minute.

greetz
back2dos

Answer 4

This is one of those questions with no answer, isnit it?

The Flash Player does support threading; however that functionality isn't exposed to developers creating applications.

Threading can be complicated and can easily be misused creating performance issues that result from creating too many threads. Adobe has traditionally made the decision not to give developers enough rope to hang themselves in terms of exposed APIs.

[although many developer's find ways to hang themselves without threading]

Answer 5

It just doesn't, there's no built-in way to do threading in ActionScript. . You can check this question for simulating fake pseudo threads.