Messages in this thread | | | Date | Sat, 17 Jul 1999 23:09:45 +1000 | From | Richard Gooch <> | Subject | Re: 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/
| |