>On Tue, Jun 04, 2019 at 09:46:04PM +0000, Zakharychev, Bob wrote: >> I mean it returns 0. What happens is that as soon as the other side >> (haproxy) terminates, poll() starts returning immediately with >> positive return value and POLLIN being the only flag set in >> fd->revents as if there's something to read and descriptor is still open. >> read() then returns 0. Rinse, repeat. > >OK so this is a valid detection of end of response. > >> Since original VTest code only breaks the poll/read loop if either >> POLLHUP or POLLERR are also set in revents, which doesn't happen here >> for some reason, > > You should see POLLHUP and POLLERR as optimizations : when the system already > knows there will be such events it may place them, but similarly they could > also > happen between the moment you check the events and the moment you decide > to read, so really a read() should always check for error and for zero.
Thanks for the explanation. I was under impression I'm missing something obvious here, but if this is expected behavior then I guess my workaround is not really a workaround. π >> the loop never breaks until the thread itself times out (10 seconds) >> and gets killed. This, however, results in a "failed" test from VTest >> perspective. I think I can #ifdef __CYGWIN__ my changes to keep >> original behavior intact where it's known to work. > I'd say "s/is known to work/happens to work/" :-) Probably that an issue > should be > filed on this specific point for vtest to improve it (and its portability). > After all, nothing > prevents poll() from being implemented using select() and it should work in > this situation. Looking at Cygwin poll() source code it's actually the way it's implemented: using cygwin_select(), which seems to be a wrapper around pselect(). I'll suggest my patch to vtest. Bob
