Why doesn't Flex/ActionScript currently support threading?
+1
A:
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.
Fernando
2010-06-15 16:31:27
+3
A:
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]
www.Flextras.com
2010-06-15 17:15:47
I had read somewhere that if flex supports threads then it will substantially increase size of flash player. So reduce size of flash player they had omitted thread feature. Is it true ?
Silent Warrior
2010-06-15 17:18:15
Flex is a SDK that includes a user interface framework and compiler. It creates SWF files that will run in the player. Nothing added to the Flex SDK will increase the size of the Flash Player; just like adding more sing into a playlist does not increase the size of your media player. Will exposed threading support in the Flash Player increase it's size? Will threading support increase sWF size? I have no idea.
www.Flextras.com
2010-06-15 18:43:22
@www.Flextras.com - I think so swf is run by flash player, so if swf have multithreading capability then to support it flash player have to include some more code (to provide runtime thread capabilities). Its like if mediaplayer wants to support more codecs/formats then they have add some more code which will eventually increase media player size.
Silent Warrior
2010-06-16 17:15:44
+1
A:
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
back2dos
2010-06-15 17:52:24
+4
A:
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
RJ Owen
2010-06-15 20:21:34