diff options
Diffstat (limited to 'indra/llcommon')
-rwxr-xr-x | indra/llcommon/tests/llleap_test.cpp | 17 |
1 files changed, 0 insertions, 17 deletions
diff --git a/indra/llcommon/tests/llleap_test.cpp b/indra/llcommon/tests/llleap_test.cpp index 653b043de4..2d88e2c676 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) { |