4 ms·

Windows uses alot of loops to process events at the api level. Different runtimes can have different threading models, it appears Node.js is running their loop

Windows uses alot of loops to process events at the api level. Different runtimes can have different threading models, it appears Node.js is running their loops in a cooperative threading model, so they are not spawning "true" threads but pseudo threads, which all run off 1 thread. It also looks like node.js is a bit like Java in that it has a multi platform backend to run code on a variety of platforms. Windows as an OS allows both threading models, and the explanations seen in windows literature for event driven processing can be applied with albeit sometimes different terminology to other languages and runtimes. https://learn.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues https://learn.microsoft.com/en-us/windows/win32/winmsg/using... True threads also allow a few more options, like thread priority and thus more cpu time to complete a task, unlike the 1 thread cooperative threading model, which all run at the fixed rate of the 1 thread. Because of this, true threads can mask the time to process a large file, if it can detect the file size and automatically give the thread a higher cpu priority to reduce the job time when the thread is started. True threads with faster cpu priority are an attack vector, because a true thread with maximum cpu priority coule read and make changes to a file as its being written out by a thread running at normal priority especially if read write by others is allowed and there is no transactional file locking in operation. Think of it like a blind brick layer working at a fixed speed, and another faster person is able to change the bricks once they have been laid, or before being picked up by the blind brick layer. Performance of threads can be controlled by the OS when looking at cpu scheduling a system wide setting which requires reboots. https://en.wikipedia.org/wiki/Scheduling_(computing)#Scheduling_disciplines https://en.wikipedia.org/wiki/Scheduling_(computing)#Schedul...

ttfkam 3y ago
With async/await and callbacks, it's as you say. I/O-based concurrency is by far the most common in JS, and I'd even go so far as say in almost any language. Not everyone needs multiple tasks using CPU at the same time nor are all tasks easily decomposable/parallelizable. However, almost all programs need to read and write files from disk, load resources from network, or a combination of the two with queries to a database. All of these do not require threads but rather non-blocking I/O. The vast majority of programs are waiting for someone else to do work rather than doing parallelizable work itself. As an aside, JS also support true threads in the form of Worker but does so in a way that prevents deadlocks while also not using explicit locking mechanisms. You are correct that there are no low-level facilities for thread (de)prioritization. Then again, if you needed that low-level fine-grained control, you'd either not be using JS or you'd write a module in a language that does for that one narrow instance where profiling has determined it will help. A large majority of the time in any language, the naive, readable approach is sufficient. Only after profiling exactly where the hotspots are should you go spelunking.
- darkclouds 3y ago
  > A large majority of the time in any language, the naive, readable approach is sufficient. But it also hides an attack vector I've yet to find mentioned anywhere, in much the same way multi cores can also help hide data manipulation, compared to a single core.
- hinkley 3y ago
  Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem. Isolates can transfer ownership of data, but the current primitives are just godawful. It’s like someone built a foot trebuchet out guns. I tend to think of myself as pretty damned sharp, especially about concurrency, and I would not trust myself to get that code right. I can’t think of anyone I would, and I used to know some people on the Java Concurrency committee. It’s a non-feature. So what most people do is messaging, which is pretty un-exotic RPC.
  - darkclouds 3y ago
    I think this is a useful link. https://stackoverflow.com/questions/1762418/what-resources-are-shared-between-threads https://stackoverflow.com/questions/1762418/what-resources-a... But this is in the context of todays "modern operating systems", other operating systems, past and present might have different terminology and ways of working, just like the terminology used in frameworks/runtimes can differ. Half the problem with any domain of knowledge, is trying to acquire accurate knowledge in the first place.
  - ttfkam 3y ago
    > Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem. I see no inherent fighting over shared state in Rust yet it clearly supports threads. "True threads" don't "fight" over shared state; they transfer ownership, whether that be through a borrow checker or with a mutex. The "fight" generally occurs when you get ownership wrong, such as in C++ or Java. It's a distinction without a difference to identify them as isolates. Do you have as much flexibility with JS as with other languages that support parallelism? Of course not; that wasn't the design goal and usability tradeoff for JS. However, transferring ownership of shared state between two or more actively running execution environments within the same process (which is what Workers do in JS) is what most folks would describe as threads. Isolates are in fact a subset of… threads. All isolates are threads but not all threads are isolates.

ttfkam 3y ago

With async/await and callbacks, it's as you say. I/O-based concurrency is by far the most common in JS, and I'd even go so far as say in almost any language. Not everyone needs multiple tasks using CPU at the same time nor are all tasks easily decomposable/parallelizable. However, almost all programs need to read and write files from disk, load resources from network, or a combination of the two with queries to a database. All of these do not require threads but rather non-blocking I/O. The vast majority of programs are waiting for someone else to do work rather than doing parallelizable work itself. As an aside, JS also support true threads in the form of Worker but does so in a way that prevents deadlocks while also not using explicit locking mechanisms. You are correct that there are no low-level facilities for thread (de)prioritization. Then again, if you needed that low-level fine-grained control, you'd either not be using JS or you'd write a module in a language that does for that one narrow instance where profiling has determined it will help. A large majority of the time in any language, the naive, readable approach is sufficient. Only after profiling exactly where the hotspots are should you go spelunking.

darkclouds 3y ago
> A large majority of the time in any language, the naive, readable approach is sufficient. But it also hides an attack vector I've yet to find mentioned anywhere, in much the same way multi cores can also help hide data manipulation, compared to a single core.
hinkley 3y ago
Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem. Isolates can transfer ownership of data, but the current primitives are just godawful. It’s like someone built a foot trebuchet out guns. I tend to think of myself as pretty damned sharp, especially about concurrency, and I would not trust myself to get that code right. I can’t think of anyone I would, and I used to know some people on the Java Concurrency committee. It’s a non-feature. So what most people do is messaging, which is pretty un-exotic RPC.
- darkclouds 3y ago
  I think this is a useful link. https://stackoverflow.com/questions/1762418/what-resources-are-shared-between-threads https://stackoverflow.com/questions/1762418/what-resources-a... But this is in the context of todays "modern operating systems", other operating systems, past and present might have different terminology and ways of working, just like the terminology used in frameworks/runtimes can differ. Half the problem with any domain of knowledge, is trying to acquire accurate knowledge in the first place.
- ttfkam 3y ago
  > Workers aren’t “true threads” they’re isolates. True threads share state. True threads in fact fight over shared state, which is the problem. I see no inherent fighting over shared state in Rust yet it clearly supports threads. "True threads" don't "fight" over shared state; they transfer ownership, whether that be through a borrow checker or with a mutex. The "fight" generally occurs when you get ownership wrong, such as in C++ or Java. It's a distinction without a difference to identify them as isolates. Do you have as much flexibility with JS as with other languages that support parallelism? Of course not; that wasn't the design goal and usability tradeoff for JS. However, transferring ownership of shared state between two or more actively running execution environments within the same process (which is what Workers do in JS) is what most folks would describe as threads. Isolates are in fact a subset of… threads. All isolates are threads but not all threads are isolates.