Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Message-ID: <00bd01c078eb$0c7696c0$011aa8c0@godzilla>
From: "David Reid" <dreid@jetnet.co.uk>
To: "APR Development List" <dev@apr.apache.org>
Subject: Keeping track of socket settings...
Date: Sun, 7 Jan 2001 20:47:14 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

[This is from a discussion on new-httpd]

dean posted as follows..

the {get,set}sockopt stuff is TCP_NODELAY and CORK.  those aren't terribly
expensive system calls at all... but it's still tempting to clean them up.
i'd say that since all sockopt calls go through APR it can keep track
of the current state -- it could even defer setting TCP_NODELAY until
a naked write comes along (i.e. a write which isn't part of a sendfile
sequence which uses CORK).

btw, the sendfile code for linux does a bunch of "if (corked)" tests --
conditionals like that can slow stuff down especially since the most
common usage is going to be one sendfile per response, and it'll always
have headers and always be corked.  it doesn't hurt to always cork.

F_GETFL followed by F_SETFL -- i'm not aware of any case where we have
to do the F_GETFL.  we know we want O_RDWR|O_NONBLOCK and can set it
directly.  worst case scenario is that we can figure something like this
out at config time (or maybe have a hint or whatever so that on linux,
solaris and probably freebsd we just set O_RDWR|O_NONBLOCK directly).

i haven't looked into what's causing the read/EAGAIN -- the response
here had "Connection: close", and there should be no need to read before
going into lingering close.

Some of this is apr specific, so ...

It seems like a good idea to keep track of what we have set as the socket
options.  Should we simply use a variable (apr_int32_t umask for example)
and check the bits?  Would this work across all platforms?  Bill?  Brian?

david