[lkml]   [1998]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...
    On Thu, 25 Jun 1998, Erik Corry wrote:

    > On Thu, Jun 25, 1998 at 04:55:38PM +0800, David Luyer wrote:
    > > I don't know the specification for a sendfile() but lets say it was
    > >
    > > sendfile(fd-in, fd-out, options);
    > OK, I agree this opens up a lot of new possibilities. Even more
    > if you include a size_t length parameter. I was thinking it was
    > going to be a clone of NTs web-server-syscall, which as far as I
    > know is limited to sending entire files verbatim onto a socket.


    The function is:

    BOOL TransmitFile( SOCKET hSocket,
    HANDLE hFile,
    DWORD nNumberOfBytesToWrite,
    DWORD nNumberOfBytesPerSend,
    LPOVERLAPPED lpOverlapped,
    LPTRANSMIT_FILE_BUFFERS lpTransmitBuffers,
    DWORD dwFlags

    lpTransmitBuffers allows for headers and trailers. Even better would be
    something that allows you to specify a starting offset without having to
    seek(), since that will require a mutex to have multiple threads doing it
    on the same descriptor.

    HPUX's sendfile is:

    ssize_t sendfile(int s, int fd, off_t offset, size_t nbytes,
    const struct iovec *hdtrl, int flags);

    which allows headers and trailers as iovecs.

    You can either have the socket closed after you finish sending, or left
    open, or (with TransmitFile) changed into an unbound, unconnected socket
    ready for reuse.

    For TransmitFile, see:

    The sendfile() man page is available at some HPUX web site too.

    Another enhancement MS has done is AcceptEx(). See:

    What it does is both do an accept() and give the first block of data
    received in one syscall. What you end up doing, AFAIK, is you can have
    TransmitFile change the socket handle into something you can pass right to
    a AcceptEx(), avoiding the destruction then creation of some of the socket

    And it isn't just a "web-server-syscall".

    > > Also, there's a hell of
    > > a lot of static web content out there you know. Images and the like,
    > > probably the bulk of web content by volume.
    > Yes, but is it the bulk of web content by server-CPU-time?
    > How often is the speed of the server serving static
    > web content really a bottleneck? There are so many other
    > likely bottlenecks, like disk bandwidth (sendfile doesn't help

    It can end up saving some disk bandwidth by allowing more efficient use of
    memory and allowing more room for buffering.

    > here as far as I can see), CPU speed for cgi, bandwidth to the
    > net, bandwidth on your Ethernet, etc. Linux/Apache can easily
    > saturate a 10mbits Ethernet already, how many people actually
    > have a faster connection to the net?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:43    [W:0.021 / U:18.580 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site