Messages in this thread |  | | From | Marty Fouts <> | Subject | RE: thread rant [semi-OT] | Date | Sat, 2 Sep 2000 16:37:38 -0700 |
| |
just an aside on asynchronous i/o: concurrency by asychronous I/O actually predates concurrency via thread-like models, and goes back to the earliest OS-precursors. Early work on thread-like concurrency models were, in part, a response to the difficulties inherent in getting asynchronous I/O right, and so now the pendulum is swinging back.
A pedantic nit: the basic Un*x I/O model, with syncrhronous interfaces predates Un*x networking by some time. I woudl make the case that the people who grafted Un*x networking (most notably sockets) onto Un*x didn't really understand the I/O model, and crafted cruft, that just happened to have a few usable features, one being a sort-of way of sometimes getting asynchrony.
Prior to posix, by the way, there were any number of Un*x variants that asynchronous I/o models, supporting any number of i/o completion notification models, buffering schemes and (lack of) cancellation semantics. My personal favorite was the variant in the Cray-2 Unicos; my personal least favorite was Intergraph's Clix.
Marty
-----Original Message----- From: Dan Maas [mailto:dmaas@dcine.com] Sent: Friday, September 01, 2000 11:50 PM To: linux-kernel@vger.kernel.org Subject: Re: thread rant [semi-OT]
[...]
Can we do better? Yes, thanks to various programming techniques that allow us to keep more of the system busy. The most important bottleneck is probably the network - it makes no sense for our server to wait while a slow client takes its time acknowledging our packets. By using standard UNIX multiplexed I/O (select()/poll()), we can send buffers of data to the kernel just when space becomes available in the outgoing queue; we can also accept client requests piecemeal, as the individual packets flow in. And while we're waiting for packets from one client, we can be processing another client's request.
The improved program performs better since it keeps the CPU and network busy at the same time. However, it will be more difficult to write, since we have to maintain the connection state manually, rather than implicitly on the call stack.
So now the server handles many clients at once, and it gracefully handles slow clients. Can we do even better? Yes, let's look at the next bottleneck - disk I/O. If a client asks for a file that's not in memory, the whole server will come to a halt while it read()s the data in. But the SCSI/IDE controller is smart enough to handle this alone; why not let the CPU and network take care of other clients while the disk does its work?
How do we go about doing this? Well, it's UNIX, right? We talk to disk files the same way we talk to network sockets, so let's just select()/poll() on the disk files too, and everything will be dandy... (Unfortunately we can't do that - the designers of UNIX made a huge mistake and decided against implementing non-blocking disk I/O as they had with network I/O. Big booboo. For that reason, it was impossible to do concurrent disk I/O until the POSIX Asynchronous I/O standard came along. So we go learn this whole bloated API, in the process finding out that we can no longer use select()/poll(), and must switch to POSIX RT signals - sigwaitinfo() - to control our server***). After the dust has settled, we can now keep the CPU, network card, and the disk busy all the time -- so our server is even faster.
[...] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |