Bob,

we have added very basic cygwin CI

https://travis-ci.com/haproxy/haproxy/jobs/205561046

it is "build only". feel free to improve it :)

ср, 5 июн. 2019 г. в 02:49, Zakharychev, Bob <bob.zakharyc...@spirent.com>:

> Willy,
>
> On Tue, Jun 04, 2019 at 05:52:12PM +0000, Zakharychev, Bob wrote:
> >> Finally got VTest compiling and working as expected (I think) under
> Cygwin.
> >> config.h had to be adjusted and vtc_syslog.c needed <netinet/in.h>
> >> included, but nothing big. However, there's some weird poll() behavior
> >> where it never raises POLLHUP or POLLERR and returns immediately with
> >> POLLIN flag raised when the other side disconnects but read()
> >> consistently returns no error and no data,
>
> > Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ?
> Because
> > the only case read() should return zero is when the end was reached.
> POLLHUP
> > is not even guaranteed to be presented at all. That's why most of the
> time you
> > see POLLHUP|POLLIN registered for the same handler.
>
> 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. 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, 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.
>
> >> so when haproxy gets killed vtc_record() keeps polling its STDOUT
> >> until the thread itself times out because poll() doesn't seem to
> >> return correct flags.
> >>
> >> I hacked vtc_record() to exit the loop when poll() returns with POLLIN
> >> raised, but read() returns 0 bytes two times in a row. This got most
> >> of the reg-tests running successfully. Now some of them fail because
> >> the expected syslog format doesn't match what HA-Proxy actually logs:
> >>
> >> **** Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053]
> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC--
> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
> >> **   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8]
> HTTP/(2\\.0...
> >> ---- Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8]
> HTTP/(2\.0|1\.1)""
>
> > Looks like it decided that non-letter characters had to be encoded.
> We're using FD_ISSET()
> > to look up the characters in the character encoding map because this was
> convenient in
> > the past, but maybe it's time to have a native implementation of a bit
> address lookup and
> > get rid of this now.
>
> > Good job!
> > Willy
>
> Thanks 😊
> Bob
>

Reply via email to