On Sat, 10 Feb 2007, David Miller wrote:
>
> Even if you have everything, every page, every log file, in the page
> cache, everything talking over the network wants to block.
>
> Will you create a thread every time tcp_sendmsg() hits the send queue
> limits?
No. You use epoll() for those.
> The idea is probably excellent for operations on real files, but it's
> going to stink badly for networking stuff.
And I actually talked about that in one of the emails already. There is no
way you can beat an event-based thing for things that _are_ event-based.
That means mainly networking.
For things that aren't event-based, but based on real IO (ie filesystems
etc), event models *suck*. They suck because the code isn't amenable to it
in the first place (ie anybody who thinks that a filesystem is like a
network stack and can be done as a state machine with packets is just
crazy!).
So you would be crazy to makea web server that uses this to handle _all_
outstanding IO. Network connections are often slow, and you can have tens
of thousands outstanding (and some may be outstanding for hours until they
time out, if ever). But that's the whole point: you can easily mix the
two, as given in several examples already (ie you can easily make the main
loop itself basically do just
for (;;) {
async(epoll); /* wait for networking events */
async_wait(); /* wait for epoll _or_ any of the outstanding file IO events */
handle_completed_events();
}
and it's actually a lot better than an event model, exactly because now
you can handle events _and_ non-events well (a pure event model requires
that _everything_ be an event, which works fine for some things, but works
really badly for other things).
There's a reason why a lot of UNIX system calls are blocking: they just
don't make sense as event models, because there is no sensible half-way
point that you can keep track of (filename lookup is the most common
example).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
