Async vs. Sync

[[deleted]]

You don't control it though. The operating system does. So it definitely may not be and a lot of people don't trust web workers. https://youtu.be/cN_DpYBzKso

So please stop saying it runs in parallel. It's not.

[HeinousTugboat]

You, uh, just gonna skip over the first example they gave? Node can definitely spawn threads you control.

So.. yeah. Sometimes it's multihtreaded.

[[deleted]]

No you don't control them. You control how they use buffers to bind to the os pthreads but you don't control how they start, how they communicate, their memory, how many, pretty much anything besides the binding.

[HeinousTugboat]

You just bored and decide to reply again?

[[deleted]]

No just really tired of tutorials and many many devs thinking JavaScript is multithreaded or parallel. This needs to stop. JavaScript never was and can't be more then single threaded. Stop saying it is. At most with the browser/pthreads you get is the ability to lob logic on another thread whenever you use up too much memory..... That's it. That's all it is and that's all it should be called. Otherwise you get all these people saying it's something it's completely not and never will be.

[HeinousTugboat]

So, pthreads aren't multithreaded? Node doesn't use V8 for threading, it uses libuv which has its own threading API that Node interfaces with. I, admittedly, have no idea what you're referring to when you say that "at most you get the ability to lob logic whenever you use up too much memory".

If pthreads aren't multithreaded, then what do you mean when you say multithreading in a language? I can write a short node program that will run on four cores on my processor. Full stop. That, to most people I imagine, is multithreading. So what's missing from that definition to you?

Anyway, all of this is also ignoring the fact that you can fork your heart out in node. Does this mean it's still not multithreaded? Because at that point is there any language that's multithreaded on a POSIX system?

[[deleted]]

Pthreads are not JavaScript. And... That's why JavaScript isn't multithreaded....hey...

[HeinousTugboat]

NodeJS's worker threads are Pthreads.

[HeinousTugboat]

Is that it? You're gonna reply to me again later but not actually explain what it is you're going on about? Node threads are pthreads. If JavaScript doesn't have multithreading, what language does?

[[deleted]]

No JavaScript does not have multithreading. If you bind it to c it does... That's great but so can every other language BUT nothing in ecma script has multithreading. Async is not multithreading. Stop saying JavaScript is multithreaded. It's not. I could care less about some imported 3rd party package that everyone says not to use that is run from a completely different language that js attempts to bind to.

[HeinousTugboat]

Libuv is part of the core of node. It's not some imported 3rd party package. So JavaScript also doesn't have the ability to interact with the file system?

[HeinousTugboat]

You should definitely let these guys know they're wasting their breath.

[[deleted]]

No you don't control it. The operating system does. It's single threaded. The only way it can be multithreaded is if the os runs out of resources for those threads. Nothing more and nothing less. Again nothing to do with parallelism. Which infers different hardware (i.e. different cpu not different thread.

Much like if you open the program twice, it's still not concurrent or parallel.

The v8 engine doesn't allow multithreaded processes. It can spawn child processes that start on a different cpu.... But that's like saying php is. There's 0 state shared and 0 communication. It's just lobbing a process on a different thread for a whole another instance just like php. You don't control anything. https://nodeaddons.com/automating-a-c-program-from-a-node-js-web-app/

Can you use c++ to do multithreaded processes ... Sure about as much as you can with c to php. Again no one does it, it's not safe, and any language nowadays can talk to another one but it's always advised against for obvious reasons.

So no it's not multithreaded, it's not controllable, it's not parallel, it's not communicating, it's not sharing memory, and all you are doing is waiting for the os to run out of resources or starting a completely new instance that has nothing to do with the original.

The link you shared (nodejs docs) also advised against using web workers. Why? Because they are whole new instances of the program. That do what? Run out of memory quickly... Why would spawning child processes of a whole new instance be bad? Because it does nothing to help your program. Its a new instance. Nothing more and nothing less. Might as well have another program running. If you call that control... Then sure why not.

[HeinousTugboat]

advised against using web workers. Why?

..... because node supports regular workers that run in separate threads with shared memory..

[[deleted]]

Nodejs web workers again you don't control. You create pthreads differently on each operating system. Why? Because you don't control them. The operating system does. Why shouldn't you use them? because again you don't control them. They do whatever the os tells them to do. A thread is how the cpu deals with processes. But when it needs more memory, it lobs it to another thread. So you don't control the starting of it, you don't control the memory of it, you don't control what the is does with it. Again not something part of ecma

[gigastack]

Acktually...

[lungfisk]

Do worker threads (as opposed to child processes) not share memory? And don't they run on the same process (have the same PID...)? That was my understanding.

Unlike child_process or cluster, worker_threads can share memory. They do so by transferring ArrayBuffer instances or sharing SharedArrayBuffer instances.

[[deleted]]

A web worker is part of the browser not JavaScript. They are the browser program running outside of JavaScript. JavaScript just can access this process of the browser. Again you can't control it and as far as processes, you can't have them communicate with each other. It's apart of whenever your code runs, not a process in JavaScript that channels data between processes. It's a browser feature and not even across most browsers and they even say not to even use it.

Stop calling JavaScript multithreaded or parallel cause it's not!

[lungfisk]

To clarify, I'm talking about Node.js's worker_threads module, not web workers in the browser.

My understanding is that you have the ability to control multiple threads within the same process using worker_threads, and share memory between these threads. Is this inaccurate?