Hi Lukas, On Tue, Apr 12, 2016 at 02:09:29PM +0200, Lukas Tribus wrote: > Jokes aside, what troubles me here is that if it wouldn't be for 1.5, we > would probably not have found this bug at all.
Then it would not have existed at all until we found the case where buffer filling was again suboptimal on some workloads. > I'm not familiar with the specifics, but it seems the polling loop > protection in 1.6+ > can hide relevant bugs. Is there anything that can be done, to benefit from > the loop protection but in a way we can spot those issue nonetheless? > > I think nginx does emit "zero size buf" warnings in cases like this, so > bugs can be reported and fixed (but I'm not entirely sure this applies to > the polling loop protection): For example: > http://hg.nginx.org/nginx/rev/ad3f342f14ba > http://hg.nginx.org/nginx/rev/a24f88eff684 > http://hg.nginx.org/nginx/rev/6ab301ddf469 > http://hg.nginx.org/nginx/rev/4aa64f695031 Thoughts (I don't have a good low > level understanding of this issues, so please bear with me)? lukas It could be a good idea actually. We need to be careful though, as since 1.6 we have dynamic buffers and we can be woken up with too short a buffer resulting in this case happening for a valid reason. And once we have HTTP/2 we'll merge many streams into a single buffer which will lead to a similar situation where we're woken up but when trying to write, other streams will have filled the buffer as well. But I still think there are some good ideas to be exploited there. Note that we also have the CLI with "show info", so it could be trivial to add stats for "nothing to read" and "nowhere to write" type of events. Regards, Willy
