lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-kernel-digest V1 #4149
Albert D. Cahalan writes:
> This should be obvious, but: threads, signals, and the use of
> multiple processes are all kludges. Die, die die!!! :-) Blocking
> system calls are crap, and interruptible calls are extreme crap. It
> is better to go with something a bit more like SCSI. One could fire
> off system calls in groups, finish some useful work, then wait for
> completion of any system calls whose results are needed.

Two weeks ago I would have been more convinced of this argument. But
after hearing DaveM talk about networking scalability, I'm becoming
convinced that blocking is *right*, and non-blocking or asynchronous
I/O is the wrong approach.

Using blocking I/O and a thread per connection means that we can push
input packet processing into the process execution context. And that
in turn means we can scale our network stack far beyond what anyone
else is doing. There's some fascinating stuff that Dave and Linus are
working on here. And it looks like it ties in very nicely with TCP's
anti-congestion algorithms.

The main downside that I can see is the requirement to support large
numbers of threads. The current limits are being worked on. After
that, the main issue I see is the resource usage of tens of thousands
of threads, particularly with the kernel stack per thread. And I think
we can solve that problem too.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.052 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site