> Allow modules that add sockets to the ap_listeners list to > define the function that should be used to accept on that > socket. Each MPM can define their own function to use for > the accept function with the MPM_ACCEPT_FUNC macro. This > also abstracts out all of the Unix accept error handling > logic, which has become out of synch across Unix MPMs. > > The code flow is much easier now for different transports: > > 1) During pre-config, post-config or while parsing the config > file, add a socket to the ap_listeners list, making sure to > define an accept function at the same time. > > 2) MPMs find the correct listener, and call the accept function > that was defined in step 1. > > 3) That accept function returns a void pointer, which is passed > to the create_connection hook. > > 4) create_connection adds the correct low-level filters.
This is basically done now. There are a lot of optimizations that can be added on top of it though. Bill Stoddard suggested turning the create_connection hook into a callback for performance reasons. MPMs should be modified to use this model, and all Unix MPMs should be using unixd_accept, so that the errror handling is common code. Each Unix MPM has an ap_listeners list, and a listensocks array, both hold the same information, they should be combined. Perchild should implement it's own transport layer, which will allow us to remove some of the hacks that used to be required. Essentially, I was adding a lot of hacks to that code to make it all work. The pipe_of_death can be put into the ap_listeners array cleanly now, and the accept function would just do the right thing. We could remove a lot of the special code to handle that condition. The code just needs to be scrubbed, and Greg commented on a hook using the wrong macro earlier today. That needs to be fixed. The proxy needs to be fixed to not write directly to the socket. Hopefully, I'll get to that tonight. I'm sure there are more, but that is the list I am working off of right now. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
