|Written by Ian Elliot|
|Monday, 17 April 2023|
Page 1 of 4
Now Available as a Book:
You can buy it from: Amazon
The sort of asynchronous function we constructed in the previous chapter is more like simulated async rather than the real thing. It is simply a way of breaking up the execution into small chunks that release the UI thread to handle events before starting on the next chunk. This is not how the system provided non-blocking functions do the job. They generally start another thread of execution to do their allotted task and free the UI thread only to use it again when the task is complete and the callback has to be run.
Thus most asynchronous programming that occurs in practice is where another thread of execution is used to complete a long running task while the UI thread gets on with what it is supposed to do i.e. look after the UI.
There is also the very real possibility that the hardware supports multiple cores and the other thread might well be really running in parallel with the UI thread. That is, the OS can implement true parallel execution and this makes things work faster.
This is also the basis of the Service worker facility that is used in the construction of progressive web apps – which are likely to be the next big thing in web app design. The Service Worker is the subject of Chapter Ten.
First we need to recap the basic principles of using a Web Worker.
Basic Web Worker
The good news is that Web Worker is very easy to use.
What is slightly difficult to get to grips with is working out what you are not allowed to do and achieving simple communication between the threads.
Ideally you should wrap any Web Worker tasks you create as Promises to make the code easier to use. We will take a look at how to do this in Chapter Seven – for the moment let's concentrate on using Web Workers raw.
There really is only one key object when using Web Workers, the Worker object.
So for example, if you have a program stored in myScript.js the instruction to run it is:
var worker=new Worker("myScript.js");
Although this is simple there is a subtlety that you need to get clear if you are to avoid making silly mistakes.
When you create a Worker object two things happen.
If you think that this is obvious and doesn't need to be said, so much the better.
In the example given above worker is an object that exists on the UI thread and "myScript.js" loaded and running in isolation from the UI thread and the program that worker belongs to. Of course the Worker object provides methods that allow communication between the two programs and this is something we have to find out how to use.
If you need to load a library into the Worker thread's code you can use the importScripts function. You simply supply the URLs of the scripts to load as parameters. The scripts are downloaded in any order, but executed in the order you specify. The importScripts function is synchronous and blocks until all of the libraries have been downloaded.
Notice that you can try and load standard libraries into a Worker thread, but as the DOM is unavailable they might not work. For example jQuery certainly doesn't work as it needs the DOM to function.
|Last Updated ( Wednesday, 19 April 2023 )|