> Just to add my (inflation-adjusted) 2 cents worth. > I may be way off on this but it sounds like you're attempting to move the > complexity from your > code down into the APR layer.
Well, yea. That is the whole story behind APR. Some folks in the Apache httpd project think APR is a bad idea because it introduces excessive complexity. From their perspactive, POSIX is a perfectly acceptable API and if an OS doesn't support POSIX then Apache shouldn't bother running on that OS :-) > I know that you can sometimes avoid a huge mess by making a > small change in a lower layer of code however I'd question whether modifying a general-purpose > library for what seems to be a highly specific one off problem is a good > idea. Sometimes you > just have to bite the bullet and duplicate-munge your code .... > G. Yes, I completely understand and have the same concern. Thought I'd offer up a patch in case there was common interest. If not, then I understand and will patch my copy of APR to do what I need. I am still interested in Roy and Ryan's assertion that this can be solved with filters. I don't see how this problem can be fixed with filters. Bill > > Bill Stoddard 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. > > > > > > ....Roy > > > > 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. > > > > On Windows, I have a kernel resident HTTP GET engine that can serve static > > content out of > > a cache very quickly. The cache is dynamically loaded by httpd as the > > server runs. > > > > httpd communicates with this cache via a custom API. This API consists of a > > cache > > management API (put stuff into the cache, take stuff out of the cache, > > refresh the cache, > > etc.), an API to enable starting/stopping/restarting the cache engine, and > > a socket like > > network API for httpd to do io with the cache. It is the network API that > > is driving my > > desire for socket iols in APR. > > > > For reasons I don't want to delve into, we decided to implement a socket > > like API for > > httpd to do network io with/through the kernel resident cache. This API is > > for most > > purposes symantically identical to the BSD socket API -for handling inbound connections-. > > It implements open(), close(), accept(), read(), write(), setopt(), etc. > > (an aside, the > > custom socket layer communicates with the Windows TCP/IP stack via the TDI > > interface in > > the Windows kernel. TDI documentation is piss poor at best and we had to > > reverse engineer > > the behaviour of many of the TDI calls which were documented incorrectly. I > > would never > > recommend anyone do TDI programming.) > > > > Consider the normal simple case of starting httpd listening on port 80. If > > the cache is > > enabled, the cache engine is started when httpd is started. httpd tells > > the cache engine > > what address/port to listen for requests on (the cache engine actually > > listens on the > > port/ip address). httpd uses it's custom socket API to handle requests > > 'punted' to httpd > > from the cache engine (cache misses). > > > > The cache engine does not support SSL. So if SSL is also enabled in > > addition to standard > > port 80, httpd needs to listen for port 443 traffic using the standard > > socket APIs (On > > windows, we use seperate thread to listen on each port so there is no issue > > of doing > > select on the two different style of socket descriptors). > > > > Hope this helps explain what I am looking for. > > > > Bill > >
