Hacker News Reader

Comment by notyourday | Hacker News Reader

> The problem that's described here - "green" threads being CPU bound for too long and causing other requests to time out is one that is common to anything that uses an event loop and is not unique to gevent. node.js also suffers from this.

Isn't node.js IO native threaded?

View on HN

I don't know, but I was actually discussing time when the thread is performing pure CPU operations and not doing any IO. In this case the JS code does not yield to the event loop, so any other requests waiting will stall.

This is actually an important property of JavaScript that allows it to work without locks (as long as you do not await, your code runs completely synchronously and will not be interrupted). It's not a flaw, but definitely requires awareness.

Gevent code that doesn't spawn more than one native thread (the one that runs the event loop) also has this property - you don't need locks as long as you do not perform IO. In Python's case it can be more tricky, as you might end up yielding to the event loop by indirectly performing IO when logging or something similar.

In JavaScript, the only case, AFAIK, where this can happen is when you await. Nothing else will cause you to yield to the event loop.

The JS event loop is kind of funny, because tasks have no priority and no preemption and so they're executed first-in first-out. If you want to avoid blocking other code paths for more than a certain length of time you need to change the order you push tasks in[0] and you need to limit execution time in some way, which can get pretty complex to reason about.

[0] by "push tasks" I mean using setTimeout, new Promise(), await, requestAnimationFrame, or similar

Ok, so it is opposite in nodejs? There's a single JS thread but as soon as it performs any async IO ( which is the only IO that one should be performing in node ), that IO creates a thread servicing that IO request. In addition to that, if one is crazy enough to run long computational operations there's setTimeout(), setImmediate() and process.nextTick() and friends.

Though I would say it doing any real compute work inline rather than farming it out to workers is a boneheaded idea regardless of the language used.

AFAIK there is only ever just one thread (that runs user code). setTimeout, etc are all also invoked by the event loop.

I can vaguely recall (but it's 1AM so I didn't verify - take with a grain of salt) that nodejs uses an a thread pool for IO, but I guess that's only for IO for which there is no async API, otherwise that would be wasteful.

I imagine a quick search about the event loop and said thread pool would yield better researched answers :)

Nodejs is single process, single thread and single core. Chrome used to run different tabs as threads of a process but that ended since Spectre and Meltdown. Back to single process since then.

  async IO creates a thread servicing that IO request

Nope. The event is a single FIFO queue implemented with libuv. It differentiates between sync and async function and basically goes around the queue running synchronous functions to completion every time it find one and async ones for a set time before switching to next one.

> Nodejs is single process, single thread and single core.

ps -eLf disagrees:

  $ ps -eLf|grep node
  deploynode     16438 16173 16438  0   11 00:21 pts/6  00:00:01 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16439  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16440  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16441  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16442  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16443  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16444  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16445  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16446  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16447  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16438 16173 16448  0   11 00:21 pts/6    00:00:00 /opt/bin/node node-le-manager-api 3550
  deploynode     16579  8353 16579  0    1 00:27 pts/4    00:00:00 grep node

> Chrome used to run different tabs as threads of a process but that ended since Spectre and Meltdown. Back to single process since then.

Chrome supports several different process models, apparently, but as Spectre/Meltdown (as well as future renderer and UXSS bugs) mitigation it now by default runs a minimum of one process per site/origin (site isolation). See https://www.chromium.org/developers/design-documents/process... and https://www.chromium.org/Home/chromium-security/site-isolati...

There are Linux system calls in wide use that are blocking. Both node.js and Golang use native threads to make the system calls and "park and wait" for the response. The runtimes then take the information from the call and incorporate it back into the user code threads(the one user thread in node.js).

The implementation of libuv under nodejs (and the state of the art python async/await) actually uses a total of three threads. It's a complicated model and it's not even strictly correct to call it an "event loop." I don't completely understand it and very few people do.

From a high level you can think of it as a single thread that can only context switch during an IO call. Otherwise the function has to run and block all the way to termination. <---- This is what rachel is complaining about.

Any good reads on that at hand?

Ok, libuv docs seem just fine. Nevermind :)

Reply on news.ycombinator.com