> On Wed, 14 Nov 2001, Bill Stoddard wrote: > > > 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. > > I'm not sure I see how that would work. The whole reason > core_output_filter does so much extra work is that there are several > different ways to write to the socket, and different ones are better in > different situations. For example, how is network_out_filter going to > know when to use sendfile() and when to use writev()? Are you suggesting > that core_output_filter will stick some metadata buckets in the brigade or > change the bucket type to some custom bucket type with a special meaning > (eg a file bucket would always get sendfiled but an iovec bucket would get > writev'd etc)? > > If it's ready, maybe the easiest thing would be if you just posted the > code for network_out_filter so we all had a better idea of what you're > proposing. Code is speech. :)
All the decisions on whether to use sendfile, etc. are made in network_out. All the code like emulate_sendfile, et. al. is moved to network_out. Bill
