> It occured to me last night that sendfile() may not be the best thing...
Its probably not. I'm not even sure if sendfile belongs in the kernel (well,
not initially, long term it probably does), but it probably does need
implementing as some point as most other OS's have or will have some variant
of it.
> my latest scheme for speeding up apache involves what I'm calling "HTTP
> flows", and the short story is that the web server has a front-end and a
> back-end. The front-end is extremely light, dumb, and single threaded;
> the back-end is full featured, and looks almost the same as current
> apache.
I've looked at the code and stuff. Looks pretty nice, but my head still
needs twisting before I can get my mind completely around it.
How does this scale for n processors, n frontends?
> The front-end handles only well-formed HTTP requests and only requests
> that fit patterns that the back-end has fed it. In its simplest form it's
> a mapping from URL to mmap-region/FD (but it can handle far more than just
> these static-only servers). If sendfile() is blocking I can't use it for
> this.
sendfile needn't be blocking, but the question is, under which conditions
should sendfile block?
For something like (al la PH-UX):
ssize_t sendfile(int s, int fd, off_t offset, size_t nbytes,
const struct iovec *hdtrl, int flags);
where s is the NETWORK socket, fd is the FILESYSTEM file descriptor.
Now, if both s and fd are set non-blocking, then logically, sendfile
shouldn't block, if s and fd are set to block, then logically it should
block.
But, what is s is blocking and fd isn't, or vice versa? I would say here we
are entitled (and perhaps should be required) to block, but its not terribly
clear what is logical in this instance.
Oh, logically being defined as what I think makes sense. YMMV.
> The backend is fully threaded (one thread per request) because it's far
> easier to let folks extend the server in a threaded programming model...
One thread/request?
I assume this means when I send "GET /index.html HTTP/0.9" it wakes up one
thread (from a preallocated pool), does the work, then sleeps (returning the
thread) ?
> the backend wouldn't have any problem with a blocking sendfile(). But the
> front-end is where sendfile() would be of the most use... right now it's a
> typical poll()/write() implementation.
>
> Food for thought... glad to see someone is thinking about sendfile() :)
As mentioned above, if async. IO can be done (at least in part) in
userspace, then I think sendfile should probably be implemented at the libc
level to start with.
Sure, this partially defeats the purpose of it to some extent, but then
again some buffer-cache + vm tweaks may make it quite viable.
-Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu