From a16f2faa8d4252c7a979c3f2783b65852656e47d Mon Sep 17 00:00:00 2001 From: Nat Goodspeed Date: Wed, 14 Mar 2012 13:14:24 -0400 Subject: Backed out changeset 51205a909e2c (Windows APR pipe bug workaround) If in fact we've managed to fix the APR bug writing to a Windows named pipe, it should no longer be necessary to try to work around it by testing with a much smaller data volume on Windows! --- indra/llcommon/tests/llleap_test.cpp | 31 +++---------------------------- 1 file changed, 3 insertions(+), 28 deletions(-) (limited to 'indra/llcommon/tests') diff --git a/indra/llcommon/tests/llleap_test.cpp b/indra/llcommon/tests/llleap_test.cpp index e01aedd7ee..1b71f7fb72 100644 --- a/indra/llcommon/tests/llleap_test.cpp +++ b/indra/llcommon/tests/llleap_test.cpp @@ -41,30 +41,7 @@ StringVec sv(const StringVec& listof) { return listof; } #define sleep(secs) _sleep((secs) * 1000) #endif -#if ! LL_WINDOWS -const size_t BUFFERED_LENGTH = 1023*1024; // try wrangling just under a megabyte of data -#else -// "Then there's Windows... sigh." The "very large message" test is flaky in a -// way that seems to point to either the OS (nonblocking writes to pipes) or -// possibly the apr_file_write() function. Poring over log messages reveals -// that at some point along the way apr_file_write() returns 11 (Resource -// temporarily unavailable, i.e. EAGAIN) and says it wrote 0 bytes -- even -// though it did write the chunk! Our next write attempt retries the same -// chunk, resulting in the chunk being duplicated at the child end, corrupting -// the data stream. Much as I would love to be able to fix it for real, such a -// fix would appear to require distinguishing bogus EAGAIN returns from real -// ones -- how?? Empirically this behavior is only observed when writing a -// "very large message". To be able to move forward at all, try to bypass this -// particular failure by adjusting the size of a "very large message" on -// Windows. When the test fails at BUFFERED_LENGTH, the test_or_split() -// function performs a binary search to find the largest size that will work. -// Running several times on a couple different Windows machines produces a -// range of "largest successful size" results... suggesting that it may be a -// matter of available OS buffer space? In any case, pick something small -// enough to be optimistic, while hopefully remaining comfortably larger than -// real messages we'll encounter in the wild. -const size_t BUFFERED_LENGTH = 256*1024; -#endif // LL_WINDOWS +const size_t BUFFERED_LENGTH = 1024*1023; // try wrangling just under a megabyte of data void waitfor(const std::vector& instances, int timeout=60) { @@ -668,13 +645,11 @@ namespace tut std::upper_bound(sizes.begin(), sizes.end(), 0, tester); if (found != sizes.end() && found != sizes.begin()) { - std::cout << "test_large_message(" << *(found - 1) - << ") is largest that succeeds" << std::endl; + std::cout << "test_large_message(" << *(found - 1) << ") is largest that succeeds" << std::endl; } else { - std::cout << "cannot determine largest test_large_message(size) " - << "that succeeds" << std::endl; + std::cout << "cannot determine largest test_large_message(size) that succeeds" << std::endl; } } catch (const failure&) -- cgit v1.2.3