• Show log

    Commit

  • Hash : 6ac8e775
    Author : Azat Khuzhin
    Date : 2018-10-21T18:31:01

    Simplify bufferevent timeout tests to reduce CPU usage in between start/compare
    
    Between start (setting "started_at") and comparing the time when
    timeouts triggered with the start (test_timeval_diff_eq), there is too
    much various things that can introduce extra delays and eventually could
    fail the test on machine with shortage of CPU.
    
    And this is exactly what happend on:
    - travis-ci
    - #262
    
    Here is a simple reproducer that I came up with for this issue:
      docker run --cpus=0.01 -e LD_LIBRARY_PATH=$PWD/lib -e PATH=/usr/bin:/bin:$PWD/bin -v $PWD:$PWD --rm -it debian:testing regress --no-fork --verbose bufferevent/bufferevent_timeout
    
    Under limited CPU (see reproducer) the test almost always has problems
    with that "write_timeout_at" exceed default timeval diff tolerance
    (test_timeval_diff_eq() has 50 tolerance), i.e.:
      FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 101 vs 50
    
    But under some setup write timeout can even not triggered, and the
    reason for this is that we write to the bufferevent 1024*1024 bytes, and
    hence if evbuffer_write_iovec() will has some delay after writev() and
    not send more then one vector at a time [1], it is pretty simple to
    trigger, i.e.:
      FAIL ../test/regress_bufferevent.c:1040: assert(labs(timeval_msec_diff(((&started_at)), ((&res1.write_timeout_at))) - (100)) <= 50): 1540155888478 vs 50
    
      [1]: https://gist.github.com/azat/b72773dfe7549fed865d439e03de05c1
    
    So this patch just send static small payload for all cases (plus a few
    more asserts added).
    
    The outcome of this patch is that all regression tests passed on
    travis-ci for linux box [2]. While before it fails almost always [3].
    Also reproducer with CPU limiting via docker also survive some
    iterations (and strictly speaking it should has less CPU then travis-ci
    workers I guess).
    
      [2]: https://travis-ci.org/azat/libevent/builds/444391481
      [3]: https://travis-ci.org/libevent/libevent/builds/444336505