3 ms·

> [javascript] makes it trivial, and practically unavoidable, to globally lock your whole runtime with every single line of code you write and import as your de

> [javascript] makes it trivial, and practically unavoidable, to globally lock your whole runtime with every single line of code you write and import as your dependencies. As someone not well-versed in js, could you describe one such case? Concurrent access to a global from two threads? Mutexes? My background is more with systems languages and I have done very little js for the browser, so I do not see that big red button.

phoe-krk 7y ago
An event loop is basically a single thread that executes functions from a FIFO queue. A function can put itself on a queue by "yielding", which means, allowing other functions to execute. If your function blocks, for example, by performing a wait on something without yielding, then nothing else gets computed because of the wait, but the event queue is occupied since the function has not yielded. This breaks the cooperative part of the cooperative multithreading mechanism of Node.
- MayeulC 7y ago
  All right, thank you. So it's basically the same as any other non-preemptive multitasking design. If the event loop is part of the Node language/runtime, I can see the case for making it preemptive.
  - Izkata 7y ago
    > So it's basically the same as any other non-preemptive multitasking design. All this has happened before. All this will happen again.
neillyons 7y ago
In Python, you can execute time.sleep(10_000) in an asyncio program, which means it wont yield back control to the event loop effecting preventing the runtime from doing anything for 10 seconds. In Javascript world I guess you could do the same by replacing time.sleep with some CPU bound code. eg a big calculation or an infinite for loop.
- tracker1 7y ago
  Yes... often JSON serialization and deserialization are the biggest blockers, if they're using puppeteer (as suggested in other comments) that can have its' own instance overhead. I think with ECS they used the "easy" button to start off with and now that they've hit those limits have had to refactor, which isn't unreasonable imho. I'm working on a project now that's very CPU bound and using limited workers behind an MQ as a distributed RPC behind a fronting API interface so that I can handle scaling... though it's also a Windows-only library involved. There's definitely an art to scaling certain types of workloads and many different options. Sometimes the simplest solution you can come up with really is the best option.

phoe-krk 7y ago

An event loop is basically a single thread that executes functions from a FIFO queue. A function can put itself on a queue by "yielding", which means, allowing other functions to execute. If your function blocks, for example, by performing a wait on something without yielding, then nothing else gets computed because of the wait, but the event queue is occupied since the function has not yielded. This breaks the cooperative part of the cooperative multithreading mechanism of Node.

MayeulC 7y ago
All right, thank you. So it's basically the same as any other non-preemptive multitasking design. If the event loop is part of the Node language/runtime, I can see the case for making it preemptive.
- Izkata 7y ago
  > So it's basically the same as any other non-preemptive multitasking design. All this has happened before. All this will happen again.

neillyons 7y ago

In Python, you can execute time.sleep(10_000) in an asyncio program, which means it wont yield back control to the event loop effecting preventing the runtime from doing anything for 10 seconds. In Javascript world I guess you could do the same by replacing time.sleep with some CPU bound code. eg a big calculation or an infinite for loop.

tracker1 7y ago
Yes... often JSON serialization and deserialization are the biggest blockers, if they're using puppeteer (as suggested in other comments) that can have its' own instance overhead. I think with ECS they used the "easy" button to start off with and now that they've hit those limits have had to refactor, which isn't unreasonable imho. I'm working on a project now that's very CPU bound and using limited workers behind an MQ as a distributed RPC behind a fronting API interface so that I can handle scaling... though it's also a Windows-only library involved. There's definitely an art to scaling certain types of workloads and many different options. Sometimes the simplest solution you can come up with really is the best option.