apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 13:08:36 GMT

> On Thursday 08 November 2001 03:53 pm, Roy T. Fielding wrote:
> > > > What you are suggesting will not work at all. There are apr_socket(and
> > > > related) calls in places other than the core_*_filters. And it is not
> > > > safe to make these calls (which will call BSD socket network io system
> > > > calls) using descriptors from a different network interface.
> > >
> > > Then I would consider the filtering logic broken.  If you can't replace
> > > the underlying network types, then we need to move all of the network
> > > calls in the core into new hooks, that can be bypassed if a different
> > > network mechanism is required.
> >
> > 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.
> Yeah, that is another way to do this.  Either way, this is the correct way to
> replace the underlying network code.
> Ryan

I don't grok what either of you (Roy or Ryan) is saying.

I have an socket-like API. I need to issue my_accept(), my_setsockopt(), my_recv(),
my_send(), my_sendfile(), et. al. These calls are scattered all across httpd. Are you
saying I need an accept() filter, a recv() filter, et. al?  Or that there needs to be a
set of generic filter APIs created specific to manipulating network options? And that each
filter should grok these APIs and pass them down all the way to the network layer?

I have to solve this problem one way or the other. I would prefer to do it open source
because the idea seems generally useful.


View raw message