8 ms·

> Since Node.js runs on a single thread, everything that will block the event loop will block everything. That means that if you have a web server with a thousa

• davidw 12y ago
  > block the event loop This is one of the problems Erlang solves: its internal scheduler keeps things running even if some code ends up in an infinite loop or otherwise misbehaves.
  • Havvy 12y ago
    Infinite loops aren't necessarily a form of misbehavior in Erlang. It is how you keep Erlang processes up after all - just spawn a function that calls itself at the end. Though the vast majority of those have a receive statement so that they're not always running.
    • davidw 12y ago
      Clearly I was not talking about the normal kind of "infinite loop", but the "malicious" sort.
• Nitramp 12y ago
  I don't think it's fair to blame developer stupidity. Formulating something asynchronously makes your code quite a bit harder to read, test, etc, so it's only natural that developers would avoid that - and builtins like JSON.parse further encourage that. Note that the author of that post doesn't really give solutions for the problems he mentions, he just tells you how to detect it. Meanwhile there are actually nice solutions for the problem of handling many concurrent computations with low overhead readily available (e.g. Go).
• LewisJEllis 12y ago
  "You're too stupid to handle this, just stick to PHP" - really? If a developer can't grasp Node well enough to avoid blocking the event loop, I certainly wouldn't want them trying to handle a thousand connected clients with PHP! Anyway, to answer your question - within a single node process no, not really. If something on the event loop goes into an infinite loop, timeouts will be of no use, and all other open requests are gonna be toast. This is just a downside to cooperative multitasking.
  • XorNot 12y ago
    Seriously. Blocking the event loop isn't "an accident that can happen" in node - it's a pretty fundamental mistake.
    • esailija 12y ago
      Using any CPU is a fundamental mistake?
      • nilliams 12y ago
        People are talking about accidentally blocking the event-loop, e.g. accidentally creating an infinite loop, not 'using any CPU'.
    • MichaelGG 12y ago
      Except they don't have the normal option available to them that event loop systems do: start another thread.
  • madawan 12y ago
    Some problems might be easier to solve in one language than in another. If you can't solve quicksort in ASM, does that mean people would be correct in wanting to refrain you from solving it in Python? It's a bit grotesque but completely analogous to your objection. It is the opinion of many that cooperative multitasking is not the way to go if you want to solve problems which require massive concurrency. PS: In Racket, you could defend against threads going into infinite loops with custodians. http://docs.racket-lang.org/more/#%28part._.Terminating_.Connections%29 http://docs.racket-lang.org/more/#%28part._.Terminating_.Con...
• louischatriot 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        Thanks. Are there no background worker process packages for nodejs that might be able to queue up some tasks?
        • rpedela 12y ago
          You want to search for "web worker" or "background task" in NPM. One example: https://github.com/audreyt/node-webworker-threads https://github.com/audreyt/node-webworker-threads
    • prawnsalad 12y ago
• lost_my_pwd 12y ago
  You can use Node's cluster API[1] directly or use a wrapping module such as Recluster[2]. With these, node will spawn a few children that get replaced when they die or time out (a little extra code is needed for the latter). One can even do rolling upgrades with this for zero downtime releases. If there is a known workload that will block for a while, one could 1) run the work in a child process, 2) consider using streams to process the data in chunks, or 3) break the work up by chaining smaller operations using "process.nextTick" to put the next operation at the end of the event loop (allows other pending operations to resume before continuing the slow/blocking work). [1] http://nodejs.org/api/cluster.html http://nodejs.org/api/cluster.html [2] https://www.npmjs.com/package/recluster https://www.npmjs.com/package/recluster
• stesch 12y ago
  Most developers don't know if they are average. I sure don't know what kind of developer I am.
• jakozaur 12y ago
  FWIW that's why Meteor, which is nodejs based, is using fibers to have thread per request. Also hot pushes give automatic restart and browser updates out of the box. Also having optional synchronous api on server, makes a lot of things easier to write. I like NodeJs, but a lot of aspects will likely prevent it became a mainstream platform.
  • driverdan 12y ago
    > I like NodeJs, but a lot of aspects will likely prevent it became a mainstream platform. Node is already a mainstream platform.