alister <alister.nospam.w...@ntlworld.com> wrote: > My main point was that when you have only 8K of ROM & 128 byte of ram you > have to think about your algorithms first.
And that also happens if you have a 32 bit system, with just 2 GB of memory available to user space (the operating system reserves the upper half of the 4 GB address space). Using threads to solve a C10K problem means you must limit yourself to e.g. 150KB of memory (including stack space) per thread. Is that doable? Perhaps not. Can you put 10,000 threads in the kernel and hope for good performance? On Windows, yes, at least since Windows 2000. On Linux? Only recently. That I think was the real argument for asynchronous i/o. Today this is not so relevant, but idea that asynchronous i/o is fundamentally better than threads is still with us. So what we are left with, then, in favor of non-blocking i/o is ability to time-out a non-responsive i/o operation. But that does not mean we need an asynchronous event-driven server. (Actually we can time-out blocking i/o with threads, but it involves using two threads per connection instead of one.) Sturla -- https://mail.python.org/mailman/listinfo/python-list
