Messages in this thread | | | Date | Wed, 24 Jun 1998 19:15:17 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Chris Wedgwood writes: > On Tue, Jun 23, 1998 at 06:37:58PM -0700, Dean Gaudet wrote: > > > 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.
Why bother with sendfile() if you have aio_*() available? sendfile() is a trivial wrapper to aio_*().
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |