apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Keeping track of socket settings...
Date Sun, 07 Jan 2001 21:40:14 GMT
On Sun, Jan 07, 2001 at 08:47:14PM -0000, David Reid wrote:
> [This is from a discussion on new-httpd]
> 
> dean posted as follows..
>----start----
> 
> 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.
>----end----
> 
> 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?

It should definitely work across all platforms. When you stop and realize
that APR has a portable setsockopt() interface, then we simply track *those*
flags. We don't have to track what's happening at the platform-specific
level.

You've got 10 flags listed in apr_network_io.h. Just keep those flags in the
socket structure in an "int" somewhere (no need to get complicated with an
apr_int32_t).

When an apr_setsockopt() actually changes one of the flags, then you reflect
that down into the platform-specific socket.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message