From 33649e848b34dcaa5f4be49862fcbf0a49b46df3 Mon Sep 17 00:00:00 2001
From: Nat Goodspeed <nat@lindenlab.com>
Date: Mon, 12 Jan 2015 12:11:37 -0500
Subject: [PATCH] Experimentally try full-size LLLeap stream test on Windows.
The new toolchain may (!) have fixed a longstanding bug in LLLeap / APR when
we try to pump large volumes of data through a Windows named pipe using APR
nonblocking I/O. This used to fail pretty consistently because the APR
nonblocking write call would sometimes spuriously return "would block" when
in fact the data buffer was completely written; the caller would later retry,
which of course would duplicate some of the data in the pipe. Preliminary
experiments with VS 2013 suggest this may have been resolved. This changeset
is to propagate the experiment to a wider range of Windows systems; we may
need to revert it if in fact the bug persists.
---
indra/llcommon/tests/llleap_test.cpp | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/indra/llcommon/tests/llleap_test.cpp b/indra/llcommon/tests/llleap_test.cpp
index 653b043de4f..2d88e2c676b 100755
--- a/indra/llcommon/tests/llleap_test.cpp
+++ b/indra/llcommon/tests/llleap_test.cpp
@@ -38,24 +38,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.
-const size_t BUFFERED_LENGTH = 65336;
-#endif // LL_WINDOWS
void waitfor(const std::vector<LLLeap*>& instances, int timeout=60)
{
--
GitLab