I was reading about web workers, and I understood that it runs on a separate thread. One doubt I have is, whether the web worker spawns a new thread for every request sent to it. Example, if I have 2 js files wherein I share a webworker between two. Now when I postmessage from both files to web worker, will two threads be created or a single one ?
No, each Worker is a single thread, and they still use the same event loop mechanism as the main execution context; meaning, for example, if your Worker runs into an infinite loop, it will lock up completely and not react to any further messages.
Related
I've read in many places (including here, in Stack Overflow) that web workers can be killed and restarted by the browser at any time. Well, probably "at any time" means "as long as they are doing something", but the thing is that they can be killed and restarted by the browser without prior warning, losing any data stored in globalThis.
But for the life of me I cannot find that in the specification, and it worries me because I'm actually using a Web Worker whose proper functioning relies in keeping some info data in a global variable to keep minimal state between calls of the message handling function.
This web worker works like a charm, and state is kept unless of course the page is refreshed, but I'm afraid that the app can fail if the browser decides to restart the web worker, and for sure it will if that happens.
I've googled about this, specially looking for examples and alternatives for rewriting my web worker without the need for that global state, but I haven't found anything relevant.
Can anyone point me to some official information about this?
I've read in many places (including here, in Stack Overflow) that web workers can be killed and restarted by the browser at any time.
Nope, they won't ever restart your (dedicated) Worker in any way.
The browser can kill a Worker if
The main navigable (a.k.a "page") is killed.
The Worker#terminate() method has been called.
The DedicatedWorkerGlobalScope#close() method has been called, and the current task is completed.
The Worker becomes "orphan". This may happen when it stops being a "protected worker", i.e.
when the Worker is a sub-Worker (itself created from a Worker) and its owner has been killed,
or when it has no scheduled tasks, no ongoing network request or database transaction, and no MessagePort or inner Worker objects susceptible of receiving messages from the outside.
So as long as you keep a reference to your Worker object in your main thread, and don't call yourself one of the closing methods, there is no way the Worker can be killed by the browser.
Note: The rules for SharedWorkers, ServiceWorkers, and other Worklets are all different, this answer treats only Dedicated Workers, created from new Worker().
I am confused about how Callstack, CallbackQueue, and Eventloop work for multiple tabs.
Is the same Callstack, CallbackQueue, and Eventloop shared by multiple tabs of the browser or does it create a new instance of the whole thing every time a new tab is created?
Same question regarding multiple NodeJS services running on the same machine.
For example, if service A is running on port 8080 and service B is running on Port 8181. Will both services share Callstack, CallbackQueue, and Eventloop?
If they are shared then will service A affect performance of service B and same for Tab will Tab A affect performance of Tab B?
Every window or tab is independent, analogous to a process in an operating system. – Barmar
The same goes for NodeJS processes. Each service is a separate process. Unless one process is using all your hardware resources or bandwidth, they have little to no impact on each others' performance.
I'm planning on building some backend logic on a server for personal use. Its connected to a websocket from another server and I've set code to handle data from that socket. I'm still fairly new to using websockets so the whole concept is still a little foreign to me.
If I allowed more users to use that backend and the websocket has specific logic running wouldn't it be conflicted by multiple users? Or would each user have their own instance of the script running?
Does it make any sense of what I'm trying to ask?
If I allowed more users to use that backend and the websocket has specific logic running wouldn't it be conflicted by multiple users? Or would each user have their own instance of the script running?
In node.js, there is only one copy of the script running (unless you use something like clustering to run a copy of the script for each core, which it does not sound like you are asking about). So, if you have multiple webSocket connections to the same server, they will all be running in the same server code with the same variables, etc... This is how node.js works. One running Javascript engine and one code base serves many connections.
node.js is an event-driven system so it will serve an incoming event from one webSocket, then return control back to the Javascript system and serve the next event in the event queue and so on. Whenever a request handler calls some asynchronous operation and waits for a response, that is an opportunity for another event to be pulled from the incoming event queue and another request handler can run. In this way, multiple requests handlers can be interleaved with all making progress toward completion, even though there is only one single thread of Javascript running.
What this architecture generally means is that you never want to put request-specific state in the global or module scope because those scopes are shared by all request handlers. Instead, the state should be in the request-specific scope or in a session that is bound to that particular user.
Is it conflicting for multiple users on one backend server websockets
No, it will not conflict if you write your server code properly. Yes, it will conflict if you write your server code wrongly.
I was tasked with creating a dedicated webworker instance on each page to handle sending a server request on a given interval regardless of what page the user is on. Since this must work for any browser, a shared webworker was not an option (hence why it must be loaded for each page).
I created a script, thinking that I had been creating a worker, but I was informed recently that workers were not actually being created, though the script was doing the intended function of the webworker.
The basic function of the webworker was this:
onPageLoad {
function sendHeartbeat() {
sendRequest(URL);
}
function startHeartbeat() {
if(timeToSendHeartbeat) {
sendHeartbeat();
} else {
setInterval(timeRemaining, sendHeartbeat());
}
}
}
This got me to thinking about whether or not using a webworker was even the best choice. Is there some inherent advantage to using a webworker that I am missing? Is using a webworker no more efficient than attaching a script to each page and running it as is? Or is this application just not suited for a webworker to begin with?
WebWorkers just run scripts, so they won't be faster than other methods. They shine by running in a different thread and not blocking the UI or any other code that wants to run in the main thread.
The real deciding factor is whether the code to be worker-ized runs for long enough to cause problems with the rest of the application. If you have intervals that need to fire on time or a very long-running math operation, you may want to start up a worker and let it go for a bit, then grab the results at the end.
So far as the main thread is concerned, workers and API calls are not entirely different in principal. You're sending someone else off to do the work and collecting results when they finish. Whether it happens on a server or another thread is less important, the part to focus on is the main thread is not doing the work.
Is it possible to access a shared worker created in the main thread in a dedicated worker created by that same main thread? My initial thoughts are no as this could cause a lot of concurrency issues, but I don't have a full understanding of the internals of WebWorkers yet to decide definitively.
My use case would be to have a dedicated worker open up a web socket channel with the server to retrieve a streaming data source. This data would then be sent into a shared worker that will provide functions to manipulate it and return results via transferable objects. I do not want to combine these objects into a single worker since I want to be able to plug in different modules for doing the data manipulation, and do not want to have to duplicate the code to talk with the web socket.
Is it possible to access a shared worker created in the main thread in a dedicated worker created by that same main thread?
Yes. Just create a SharedWorker as a sub-worker (and it will be shared), or create a MessageChannel between the shared and the dedicated worker.
this could cause a lot of concurrency issues
No. Inter-Worker communication is evented and asynchronous.
This data would then be sent into a shared worker that will provide functions to manipulate
That doesn't sound as if you needed a shared worker for that. For "providing functions", a simple library that is loaded into the dedicated worker (which does the websocket communication) will suffice. You might even load libraries dynamically, using some kine of dependency management in the worker. There's no need to duplicate the web socket code.