threading

[Sturla Molden]

alister <alister.nospam.ware at 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