On Wednesday 14 November 2001 10:57 am, Bill Stoddard wrote: > > 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.
Then why bother having core_output? The logic that you are leaving in the core is minimal at best. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
