> On Wednesday 14 November 2001 06:18 am, Bill Stoddard wrote: > > > On Tuesday 13 November 2001 02:37 pm, Roy T. Fielding wrote: > > > > On Tue, Nov 13, 2001 at 09:39:30AM -0800, Ryan Bloom wrote: > > > > > > I'm starting from a different place I guess. I see the core as defining > > > the client interface for TCP. The MPM just maps the client interface to > > > a worker thread. > > > > > > The way I see it, the core is the beast that is doing all of the actual > > > communication to the network, the MPM just tells which thread to handle > > > each request, regardless of where it comes from. Based on the comment > > > above, if you are going to move anything to the MPM, you will also have > > > to move the core_input and core_output filters to the MPMs, because they > > > would be actually implementing the network logic. > > > > Not necessarily. I have code to split the network io calls out of > > core_output_filter and place them in a net_out_filter. The net_out_filter > > just unconditionally writes brigades to the network. > > Then what does the core_output_filter do? All that filter should be doing is > combining buckets and writing to the network the best way possible. >
core_output_filter does buffering based on mimimum write thresholds, checks for iovec limits and multiple file buckets, and splits brigades accordingly, etc. These functions would remain in core_output_filter. The network_out_filter would simply iterate over the buckets and send their contents on the network interface (apr_sock calls or alternatives). The network_out_filter would do no buffering, no splitting brigades and no decision making regarding whether content should be sent or not. It just writes the brigade passed to it to the network and it is done. Bill
