From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Thursday, November 08, 2001 5:01 PM
> On Thursday 08 November 2001 01:34 pm, 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. This really sounds to me like you mean to -replace- the apr/network_io/unix directory with the appropriate calls for the API. I can't picture mixing one socket provider with another in a given build of the apr. Wouldn't this cause all sorts of problems if a module author called a given apr function to create a 'conflicting' socket? It seems you need a 'custom' build of apr with the appropriate stubs to this propritary library - which would superceed all socket-related calls or none. Is there an application where both the 'native' sockets and your libraries' sockets would be used in the same app? Bill
