[louischatriot]

If a dev really writes code that blocks the event loop, is not tested and not reviewed, I'm not sure he should work on professional projects ...

Anyway with one nodejs process it's not possible, but you can detect a stuck node and use some load balancing with a cluster of node processes (2 is usually enough), and simply reload a process if it gets stuck (while sending an email to ops of course). You need to use such an architecture to get zero-downtime deployments in any case .

[duncanawoods]

What would you suggest for this situation:

a low priority admin page renders a 3000 row, 30 col table on the server using react. The query and resulting page size are pretty small < 2MB but this takes 5s for react to render.

I didn't expect it to be this slow and can't use client side rendering.

[rpedela]

Those type of frameworks are great, but they all have performance limitations. The typical solutions are either find a faster framework or write it by hand. If the issue is that it is blocking the event loop rather than the literal performance, then you could spawn a process to do the React work.

[duncanawoods]

Thanks. Are there no background worker process packages for nodejs that might be able to queue up some tasks?

[rpedela]

You want to search for "web worker" or "background task" in NPM.

One example: https://github.com/audreyt/node-webworker-threads

[prawnsalad]

You could break it up so that it processes the 3000 rows in chunks of say.. 500, and use process.nextTick() between each chunk to ensure node is handling other events too.

[duncanawoods]

That would block a server for 500ms six times which is still unacceptable let alone being a hack that would mean rewriting the react page to support partial evaluation.

Your suggestion is basically to write your own event loop and write any cpu bound task to manually yield to the single-threaded node event loop. Crazy given we have been using multithreaded servers for decades that would do this automatically and generalise for any cpu-bound task.