5 ms·

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives

• uast23 15y ago
  My understanding is: When you are using a ruby or python based web framework, each request is a blocking request i.e. after each request you wait for the response before proceeding further e.g. urllib.urlopen(), which as a result causes the no of requests handled/second to go down. Using eventmachine or gevent respectively for ruby or python is one way to overcome this. In node.js there is no such concept of blocking requests and everything is processed in a single thread. But you can always fork multiple processes using its cluster module http://nodejs.org/docs/latest/api/cluster.html http://nodejs.org/docs/latest/api/cluster.html edit: Oh, I was not trying not advocate anything. nodejs is indeed just a choice, if I didn't make myself very clear when I said "My understanding is:"
  • aphyr 15y ago
    Ruby and Python (not to mention basically every other language) have a plethora of threaded, forking, and evented models for concurrency. Thin/Rack/Sinatra, for example, behaves capably in a thread-per-request mode. Reactor systems are not the only (nor are they even preferable in many cases) choice.
  • MostAwesomeDude 15y ago
    How did you find gevent and totally miss Twisted, which is linked on the front page of nodejs.org? There are a handful of frameworks that assume every request is fully concurrent and non-blocking. Twisted-based stuff is the most prevalent, for Python, like Nevow, Athena, and the stuff baked into twisted.web. However, WSGI itself doesn't say anything about the concurrency of individual requests, and it's totally possible for WSGI requests to be multithreaded, multiprocess, or otherwise concurrent.
  • mbucc 15y ago
    blocking / non-blocking has nothing to do with language; for e.g., see tornado for async request handling in python.
• wlievens 15y ago
  As soon as you're doing anything beyond CRUD on a database, you will probably have to worry about them. Unless Erlang blablabla...
• exogen 15y ago
  Node is not a web framework. It's something one might use to build a web framework. So it's a bit silly to say that 'any web framework ever' already deals will this for you – well, duh, but the framework author certainly had to deal with thread safety (possibly incorrectly). And don't say no framework user has ever screwed up shared state because they didn't realize how threadlocal works or that requests might be handled in another thread...
  • zzzeek 15y ago
    > but the framework author certainly had to deal with thread safety usually not. if your framework builds off the common web integration system for the target environment, i.e. Java Servlets, WSGI in Python, etc., you're already handed a request scope within a thread. It's only web servers and containers that really have a heavy lifting job to do.
    • exogen 15y ago
      Okay. Clone the Rails repo and do this: git log --grep thread
      • shadowsun7 15y ago
        To be fair, though, Django is not thread safe. Now while I respect Rails for taking the effort in making it thread safe (IIRC, it was a Google Summer of Code project) - it doesn't seem to be a must-have to have your framework be thread safe.
• vetler 15y ago
  You hear this when people praise node.js, and it might be true for all I know, but I have yet to see a concrete example comparing node.js code to the same code in another framework/language. Would be very interesting and help non-node.js users understand the benefits.
• russell_h 15y ago
  I think what he is getting at is that if you want to handle multiple requests within the same process (in order to have in-process shared state, so you can make your chat server without external dependencies or whatever), you either need an event loop, threads, or both. If you have threads, you do have to worry about mutexes and reentrance.
  • zzzeek 15y ago
    none of that has anything to do with writing web-request-handling code, it has to do with writing custom servers. There are plenty of asynchronous solutions for writing servers, including the very widely used Twisted platform as well as the Erlang programming language. It's a tad annoying that node.js is touted largely by front end developers as solving a supposedly previously unaddressed problem. to wit: > emerging set of programming conventions, philosophies, and values that I see evolving in the node.js community no, sorry, they've already emerged, they've already evolved. Go download Twisted. Use node.js if you happen to like it better. But it's not the fricking messiah.
    • substack 15y ago
      The asynchronous aspects were a very small piece of the article for a reason. Node is doing a lot of very interesting, important, and novel things that aren't related to asynchronous events at all. Twisted in particular suffers from too much exposed surface area and having to manage the reactor yourself, which hurts reusability a lot.
      • zzzeek 15y ago
        I'd prefer to see a detailed article about that. Also I'd like to see more detail on why exactly writing custom servers is so profoundly important all the sudden. I hardly see the advantage of even nginx over apache, though that's a different issue.
        • koen 15y ago
          WebSockets probably. None of the traditional server-side web frameworks (Ruby on Rails, Django, Java Servlets, ...) can deal with them because you need to maintain open connections with each client. That also makes asynchronous I/O important (a feature of nginx over apache). Most WebSockets solutions are clumsy at best, because you need to run something independent from the rest of your web stack. Unless you use solutions like Wt (http://www.webtoolkit.eu/wt http://www.webtoolkit.eu/wt).
• bradleymeck 15y ago
  When working with requests that share resources via web frameworks that deal with threads, the large consensus is to put the resource into an external managed resource. This external resource such as a database will manage the locking for you to prevent write conflicts, however, when caching values for complex interaction beyond CRUD you may have update conflicts where a new request has an in memory copy of an outdated resource. This is where the problem lies.
  • bretthoerner 15y ago
    Wait, how does Node solve this where others don't?
    • bradleymeck 15y ago
      By giving a shared in-memory resource for the current state of an object that is not mutated from other threads during a single stack build / teardown. Concurrent access in threads requires locking the object until it is in a determinate state, while in Node you are guaranteed the state until the stack unwinds.
      • bretthoerner 15y ago
        But this isn't unique to Node, is it? It seems like you're saying you've added a feature when you've really removed one. You can create a single threaded event loop in any language and get the same properties, no? I'd argue something like Clojure is actually providing a feature here, instead of taking something away from your toolkit. You can have a single view of an object for the life of, say, a request all while its root binding is actually being mutated by other threads. You won't "see" the new value until you deref the root binding on the next request. Except nobody stole threads from you and sent you a bill.
        • 2mur 15y ago
          Ah but node is really just the appearance of a single thread which is actually a v8 managed evented threadpool (or some such magic).