From cf1ff56f3c8a7a55fa38bcdda3907147d25382a2 Mon Sep 17 00:00:00 2001
From: Alex Crichton <alex@alexcrichton.com>
Date: Mon, 27 Jul 2015 16:10:59 -0700
Subject: std: Remove msvc/valgrind headers

These aren't really used for anything any more, so there doesn't seem to be much
reason to leave them around in the `rt` directory. There was some limiting of
threads spawned or tests when run under valgrind, but very little is run under
valgrind nowadays so there's also no real use keeping these around.
---
 src/libstd/rt/mod.rs  |  2 +-
 src/libstd/rt/util.rs | 32 --------------------------------
 2 files changed, 1 insertion(+), 33 deletions(-)

(limited to 'src/libstd/rt')

diff --git a/src/libstd/rt/mod.rs b/src/libstd/rt/mod.rs
index 0ac0d03e19d..7e86bb775a1 100644
--- a/src/libstd/rt/mod.rs
+++ b/src/libstd/rt/mod.rs
@@ -26,7 +26,7 @@ use sys;
 use usize;
 
 // Reexport some of our utilities which are expected by other crates.
-pub use self::util::{min_stack, running_on_valgrind};
+pub use self::util::min_stack;
 pub use self::unwind::{begin_unwind, begin_unwind_fmt};
 
 // Reexport some functionality from liballoc.
diff --git a/src/libstd/rt/util.rs b/src/libstd/rt/util.rs
index 031fda089c8..0fe8d873a75 100644
--- a/src/libstd/rt/util.rs
+++ b/src/libstd/rt/util.rs
@@ -16,38 +16,6 @@ use intrinsics;
 use sync::atomic::{self, Ordering};
 use sys::stdio::Stderr;
 
-/// Dynamically inquire about whether we're running under V.
-/// You should usually not use this unless your test definitely
-/// can't run correctly un-altered. Valgrind is there to help
-/// you notice weirdness in normal, un-doctored code paths!
-pub fn running_on_valgrind() -> bool {
-    return on_valgrind();
-    #[cfg(windows)]
-    fn on_valgrind() -> bool { false }
-
-    #[cfg(unix)]
-    fn on_valgrind() -> bool {
-        use libc::uintptr_t;
-        extern {
-            fn rust_running_on_valgrind() -> uintptr_t;
-        }
-        unsafe { rust_running_on_valgrind() != 0 }
-    }
-}
-
-/// Valgrind has a fixed-sized array (size around 2000) of segment descriptors
-/// wired into it; this is a hard limit and requires rebuilding valgrind if you
-/// want to go beyond it. Normally this is not a problem, but in some tests, we
-/// produce a lot of threads casually.  Making lots of threads alone might not
-/// be a problem _either_, except on OSX, the segments produced for new threads
-/// _take a while_ to get reclaimed by the OS. Combined with the fact that libuv
-/// schedulers fork off a separate thread for polling fsevents on OSX, we get a
-/// perfect storm of creating "too many mappings" for valgrind to handle when
-/// running certain stress tests in the runtime.
-pub fn limit_thread_creation_due_to_osx_and_valgrind() -> bool {
-    (cfg!(target_os="macos")) && running_on_valgrind()
-}
-
 pub fn min_stack() -> usize {
     static MIN: atomic::AtomicUsize = atomic::AtomicUsize::new(0);
     match MIN.load(Ordering::SeqCst) {
-- 
cgit 1.4.1-3-g733a5