Re: Thread implementations...

Marc Slemko (marcs@znep.com)
Thu, 25 Jun 1998 23:15:11 -0700 (PDT)


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.

No.

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:

http://premium.microsoft.com/msdn/library/sdkdoc/wsapiref_3pwy.htm
http://premium.microsoft.com/msdn/library/conf/html/sa8ff.htm

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

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

http://premium.microsoft.com/msdn/library/sdkdoc/wsapiref_17jm.htm

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
structures.

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?

Enough.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu