When and Where can we use Workers


Workers are great but as the feature been added gradually sometimes it’s hard to know where they are available

here a small summary

Flash 11.4 / AIR 3.4 (SWF17)
Workers for SWF and Desktop

Flash 11.9 / AIR 3.9 (SWF22)
Workers for Android

Flash 19 / AIR 19 (SWF30)
Workers for iOS

Redtamarin 0.4
Workers for Windows, Mac OS X and Linux

To put it another way,

since Flash 19
since AIR 19
since Redtamarin 0.4

you can use workers everywhere :slight_smile:

The Maturity Level of the Admin/Moderator of this Forum
The Wonderful World of Flash Communities

So should I skip Signals and go straight to Workers or do they both have their own merits in different situations? Sorry could probably google the answer but its just a thought bubble :wink:


Since workers are finally available on all targets… there is a need to update many common libs to use them… first thought?

Starling AssetManager, which freezes the app for a while!


hey we are here to discuss so no prob :wink:

Signals and Workers are not the same thing and so not used to solve the same kind of problems.

You would use signals to have a bit faster “events” when you need events without a GUI.

You would use Workers to be able to execute code in parallel.

One of the main problem with GUI programming is to run one or many intensive tasks without freezing the UI, so for example: unzipping a 1GB file.

With Workers, by default your UI run on the “main” worker (the primordial worker, the first one created), and when you click on that “unzip” button, instead of running the code that do the unzipping inside the main worker, you will dispatch the task to a “child” worker (or also background worker), which basically allow to keep your UI snappy while in parallel the task of unzipping is executing “somewhere else”.

The thing to know is that workers are like a live copy of the current Flash Player or AIR instance, but are a bit more limited, in fact I’m bad at explaining it, better read the doc


A Worker object represents a worker, which is a virtual instance of the Flash runtime. Each Worker instance controls and provides access to the lifecycle and shared data of a single worker.

A worker allows you to execute code “in the background” at the same time that other operations are running in another worker (including the main swf’s worker). In a non-worker context some operations, for example processing a large set of data in a loop, take so long to execute that they prevent the main application thread from updating the screen quickly enough. This can cause stuttering or freezing the screen.

Using a worker allows you to perform a long-running or slow operation in the background. Each worker runs its code in a separate thread of execution from other workers. Long-running code in one worker does not block code in another worker from executing. Instead, the two sets of code run in parallel. Consequently, a worker can be used to execute code in the background while the main application thread stays free to continue updating the screen.

This capability of simultaneously executing multiple sets of code instructions is known as concurrency.

From there, read also the other documents like
Understanding workers and concurrency
Intro to AS3 Workers: Image Processing by Shawn Blais

In the end, you can use both Signals and Workers at the same time.


awesome link to Worker: http://blog.peteshand.net/fluid-solver-workers-agal-awesomeness/


I know that the forum is new etc. and I don’t want to sound like enforcing too strict rules

but, if you include a link, maybe add bit more context around it
see for reference this discussion on stackoverflow


OMG Workers look awesome. :slight_smile:


remember those who criticized AIR desktop apps around AIR 1.0
blaming the AIR app to feel sluggish etc.

workers solve exactly that kind of problem

but bare in mind it is much harder to program
not really the fault of workers

it’s just, in general, “multi-threaded” programming is something hard to do right, workers area bit different than multi-threaded programming and in a way simpler, but still require a lot of efforts to get some results

but the results, oh man, they totally worth it :slight_smile:


Pft harder == funner :slight_smile:
If the pay off is better quality who cares how hard it is


maybe this can help https://github.com/doublefx/easyWorker


Did you read what I wrote to @CPS comment above ?

same apply to you

providing a link is nice, but you have to give more context

have you used this library?
what do you think of it ?
give maybe a code sample you used recently?


can I spam the link, too? https://github.com/makc/worker-from-class something I forked 4 years ago and did not touch since then :slight_smile: allows you to use any mc class in your swf as a worker (i.e. wihtout 2nd swf). unlike the original, this fork brings all the other classes into virtual 2nd swf so you can use them too.

could use some improvement, e.g. one could pull all the classes to 1st frame, and maybe (way more work) filter unused classes out.



According to this blog post by MyFlashLabs, they based their library on your work: http://www.myflashlabs.com/developer-friendly-as-worker-api/.

I tried it recently and it was really easy to run a worker on a mobile device. I still need to implement it on a big project but I’ll get to it pretty soon.

I really recommend it and want to thank you both for sharing your code.


nope, that post says they have also started by forking the original repo.


You’re right, my bad.

Anyways, workers are awesome and that library makes it super simple to use them.

split this topic #16

2 posts were split to a new topic: When you get off topic

The Maturity Level of the Admin/Moderator of this Forum
The Maturity Level of the Admin/Moderator of this Forum

Ok I’ve looked at workers. If I’m correct it’s about creating multiple versions of the flash player and doing comms between them. I may be incorrect but it feels like a hack rather than true multithreading.


It’s far from a hack
as with redtamarin I’m a bit deeper in the code I can tell that those workers are based on pthreads (POSIX threads) for Linux / Mac OS X and Windows::System::Threading for Windows which are “adapted” to work like pthreads, it’s quite elegant imho.

Under a Linux-like system is you compare pthread to fork for example

with fork()

  • you create a new process by duplicating the process that become a child of the current process
  • right after the fork() system call, the next instruction is in the child process space
  • two identical copies of the computer’s address space,code, and stack are created one for parent and child

with pthread

  • you are only creating a new thread which is given access to the same process as the caller
  • threads under the same process can communicate using shared memory
  • a new thread will share data, file descriptors, signal handlers, current working directory, user ID, group ID, etc. but will have its own thread ID and stack

In the context of a VM like the AVM2 is quite clever to use pthread, and in fact we can find all the concepts reused in the API like mutex, condition, ByteArray shared memory, etc.

There are pros and cons, with fork the cons are creating a new process have a lot of overhead and it also force the 2 processes to agree on a communication channel like pipes, sockets, files, etc.

The pros of fork is that because of a cloned process the isolation is much better, you could have a child process crashing the parent would not mind as it can just kill it and create another one, and here if you compare to pthread it’s more problematic to kill only the part that this child thread was using (did it use these files? this memory?).

So yeah pthreads seems weaker but they are much lighter and faster t ocreate, and when you combine them with a VM you remove the bad part of a weak isolation, also why they are called “workers” and not “threads”.

See, a worker is something that work in the context of the pthread and have a persistent state (started, paused, terminated) and you can basically “work with it” as long as it does not go out of scope (either self terminate or terminated by the parent).

In the AVM2 implementation it is made in such a way that only very specific types of object can be shared which means when a worker instantiate a VM object it is created on its own stack and that create a “beautiful” isolation context, eg. you have access to almost everything the VM can do but if something crash in the child worker then the worker terminate without killing the main worker.

Oups got carried away :smile:

Workers in the AVM2 is like creating a new lighter instance of the AVM2
which can share specific objects without killing the main VM if something goes wrong.
In fact, even if you are not creating a worker the main VM process is considered the main worker, eg. the primordial worker.

Not a hack at all and extremely powerful.


I think I might put my efforts into dev on ANE’s, not sold on the worker


you might underestimate the work that involve, that you will not be able to hook into the AVM2 at that lower level and that your implementation may conflict with the actual workers already implemented there.

For example, under Linux you may chose between pthread and fork but it is strongly advised to not use both.

You still don’t bring any arguments why workers are bad as they are,
what are your problem with the current workers ?

Did you look at some tutorial like
Encoding BitmapData using AS3 Worker ?

In my very specific case under redtamarin, workers have solved the problem of using fork() as it is not available under Windows, so for example I can program multithreaded servers that work the same under Linux / Mac / Windows; if workers were not existing I would have probably have to implement them the way adobe did to solve that fork problem.