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
- 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
- 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
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.