5 ms·

> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how

• frou_dh 5y ago
  I like to remember that threading APIs were a later add-on after Unix had already existed for years. They're not fundamental like the Process is. Isn't it an appealing model to not even have to talk about threads because every process is 1 thread by definition?
  • astrange 5y ago
    Multiple processes are a bit easier to deal with than threads per servers - mostly because POSIX signals interacts poorly with threads. It's also more secure because you should not mix different users' requests in the same process if you can avoid it. nginx runs on a one process per core model and more or less does everything correctly.
• secondcoming 5y ago
  The downside is excessive context switching, and sharing data between processes becomes difficult (counters, etc).
• sydthrowaway 5y ago
  So what was the point of the async/callback web programming revolution if processes were good enough?
  • TeMPOraL 5y ago
    The point was that you didn't have the ability to spawn new threads at all. async lets you pretend you have threads, at the cost of everything being run through a hidden event loop.
    • cube00 5y ago
      I thought it was to get the best of both worlds in that you could max out a core with async to avoid context switching or waiting for blocked I/O but you still open up additional threads on more cores if you were becoming CPU bound.
      • merb 5y ago
        yeah, basically. a lot of people do not know, but async/await does have NOTHING do to with threads or processes. you can use threads with async/await, but you do not. async/await basically means you are running your "green threads"/tasks/promises on a event loop, the event loop can be either single threaded or it can run the stuff on multiple threads. a lot of people just did not get the difference between concurrency vs. parallelism. threads and processes are basically parallelism, while concurrency is async programming. good talk about that stuff from rob pike (go): https://www.youtube.com/watch?v=oV9rvDllKEg https://www.youtube.com/watch?v=oV9rvDllKEg
  • rakoo 5y ago
    It's because they weren't good enough for the thousands of concurrent requests of C10k or the millions that came after it with C10m. Granted, 10k concurrent requests is a problem for the 1% of websites, so processes were (and still are) good enough for the long tail of personal or small-scale websites.
  • ori_b 5y ago
    Millions of concurrent connections. On 20 year old hardware with a small fraction of the power of today's.
  • emn13 5y ago
    There wasn't a lot of point. Almost nobody needs this; but since everybody wants to do what the hyper-successful mega-scalers are doing...
  • jiofih 5y ago
    Memory use. Even though threads / processes are “cheap” right now, it wasn’t the case in the past and they are still quite far from the couple-of-kbs per connection needed in async servers. You’re not getting a million paralel processes processing requests any time soon.
  • falcolas 5y ago
    To add on to every other sibling comment, switching threads or processes requires a trip back up to the kernel space (a context switch), instead of just remaining in user space. in this switch, all of your caches get busted. Not a problem for most folks, but when you want the greatest possible performance, you want to avoid these kinds of transitions. Basically, the same reason some folks use user-space networking stacks.
• wongarsu 5y ago
  Apache's thread-per-connection model used to run basically the entire internet until nginx came along and demonstrated 10k simultaneous connections on a single server. If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process
  • einpoklum 5y ago
    If you have 100 concurrent confections you're probably baking cookies.
    • wongarsu 5y ago
      But you can probably get away with using one regular commercial oven instead of getting a baking tunnel oven :)
    • TZubiri 5y ago
      To be fair, I think it would be ideal if every service would run their own 100 concurrent connections, instead of everyone using a service that handles 1 trillion.
  • minusf 5y ago
    the default mode in apache/apache2 used to be _process_ per connection (pre forked workers) not thread per connection. threads came much later.
  • jiofih 5y ago
    You might want to review that knowledge. You can spawn a few thousand threads on a modern machine without much contention.
    • merb 5y ago
      well the thing is he confuses processes with threads. apache2-prefork used/uses processes and not threads.
• lrem 5y ago
  Linux processes are actually surprisingly lightweight, thanks to using copy-on-write memoryu. I.e. fork is cheap, exec is expensive and changing things in already allocated memory is expensive. But this execution model does not do exec and mostly allocates new buffers for anything it needs to do. As an extra benefit, you get garbage collection as a gift from the kernel ;)
• tyingq 5y ago
  Fork() on modern Linux is very fast/lightweight. This isn't true for all POSIXy operating systems though. This would perform really terribly, for example, on any Unix implementation from the early 2000s or before, and maybe on some current ones.
  • cryptonector 5y ago
    fork() is evil[0]. [0] https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234