lkml.org 
[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.117 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site