On 01/27/2016 08:50 PM, Ruediger Pluem wrote: > > > On 01/27/2016 12:46 PM, Yann Ylavic wrote: >> On Wed, Jan 27, 2016 at 10:02 AM, Plüm, Rüdiger, Vodafone Group >> <ruediger.pl...@vodafone.com> wrote: >>> >>>> -----Original Message----- >>>> From: Yann Ylavic [mailto:ylavic....@gmail.com] >>>> Sent: Mittwoch, 27. Januar 2016 09:15 >>>> To: httpd-dev >>>> Subject: Re: svn commit: r1726787 -
> >> >>> >>>> (btw that could be optimized to flush outside the loop). >>> >>> Could be. The question is, whether this is ok from the websockets >>> responsiveness point of view. >>> OTOH we do an non blocking read. So this should be fine. >> >> Yes, while successive non-blocking reads give us data I don't think we >> should "fragment" on the other side, let the core/socket buffers >> handle it. > > I am fine with flushing at the end of the loop. If no one opposes I can do > this. > Looking into this in more detail the following thoughts came up: What do we think how much iterations do we do in this loop in the typical case a.k.a how often do we call ap_get_brigade with a non blocking read? My gut feeling tells me that we only do this once at least in the websocket case. If this is the case the discussion whether to flush after the loop or in the loop wouldn't be relevant any longer, but more important: If it is ok to flush in the loop I think it would be better to add the flush bucket directly to bb_out instead of calling ap_fflush afterwards. The reason for this is that it gives downstream filters a better information on what they should do. With the current approach they might set the buckets aside and store them for later processing and only process them in the second round when they see the flush. If the flush would be on the first brigade at least some of them would process the buckets directly without setting them aside. Comments? Regards Rüdiger
