apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 18:01:25 GMT
On Friday 09 November 2001 06:07 am, Bill Stoddard wrote:
> > Not really.  It just means that the network options being set on the
> > sockets directly today should instead be set (in an abstract sense) on
> > the top of the filter chain, which would propagate them down to the
> > filter that is IO-specific.  In reality, there are only a couple types of
> > filters that would ever have a legitimate reason to set socket options,
> > and they are very close to the IO-specific filter in the chain.
> Not sure you guys understand exactly why I think I need socket iol, so I'll
> try to explain it in more detail. If there is a better, more extensible way
> to solve my problem, I am all ears but I don;t see it yet.

Bill,  I do understand what you are looking for.  Remember, I did do a little
bit of work that has involved looking at the kernel cache before.  Here is
what I am saying, there are two ways to do this:

1)  Make APR a wrapper around a bunch of different socket backends.  This
has the same problem as the DB backend issue and the lock backend issue.
Namely, it is going to be next to impossible to do cleanly. It also introduces a
bunch of logic that is really Apache specific.  In fact, this isn't even Apache
specific, there are a couple of modules that want this.

2)  Use an Apache module to implement this, using filters and hooks.

Option 2 will require investigating all of the places that we make socket calls
in Apache.

Lingering close
New connection			This could probably move to later in the code
make_sock			(only used if ap_listen_open created the socket)
close_listeners_on_exec		(only used if ap_listen_open created the socket)
find_default_family		(only used in ap_set_listener : Listen directive)
alloc_listener			(only used in ap_set_listener : Listen directive)
disable_nagle			(only used if ap_listen_open created the socket)
pod_signal			(client side)
rfc1413.c			(client side)

accept error conditions

A more exhaustive analysis might be good too, but the reality is that most of
these calls are grouped into a few very small locations in the code.  A lot of
them could move all the way down to the core_output_filter, or possibly to
the very first filter in the stack, which would always correspond to the
lowest filter.

The only really hard one is the accept stuff.  That could be done with a simple

To ensure that the core never calls a regular socket operation on your socket, 
you would put your socket in a module's configuration structure.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message