>
> On 25 Jun 1998, Stephen C. Tweedie wrote:
>
> > At the Expo, Larry McVoy made a suggestion that we allow reads and
> > writes to specify some form of token to identify the data being
> > transfered, without actually having to make the data visible in user
> > space at all.
>
> why cannot this 'token' be a file descriptor (like in Linus's suggestion)?
> Is there any valid case where we cannot associate 'stuff to be
> transferred' with a 'file'?
Consider an HTTP proxy. When a new entity is being cached, it's desirable
to "tee" the data coming from the origin server -- one copy going to disk,
and N copies going to clients requesting the object. This is pretty easy
to accomplish with mmap() or pull()/push()... increasingly difficult to
accomplish with sendfile() without going to disk first.
This thread is, uh, fun ;) I started out liking sendfile, and now I'm
thinking it may not be worth it!
Another problem with sendfile(): the file FD's seek pointer is changed
while it's used, which means multiple clients can't be serviced from the
same FD. This kind of defeats the purpose of caching the open FD in a
threaded server...
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu