about summary refs log tree commit diff
path: root/src/libstd/rt/util.rs
diff options
context:
space:
mode:
Diffstat (limited to 'src/libstd/rt/util.rs')
-rw-r--r--src/libstd/rt/util.rs26
1 files changed, 10 insertions, 16 deletions
diff --git a/src/libstd/rt/util.rs b/src/libstd/rt/util.rs
index 727bdb782d2..647d88c26f2 100644
--- a/src/libstd/rt/util.rs
+++ b/src/libstd/rt/util.rs
@@ -16,8 +16,6 @@ use option::{Some, None, Option};
 use os;
 use str::StrSlice;
 use unstable::atomics::{AtomicInt, INIT_ATOMIC_INT, SeqCst};
-
-#[cfg(target_os="macos")]
 use unstable::running_on_valgrind;
 
 // Indicates whether we should perform expensive sanity checks, including rtassert!
@@ -37,21 +35,17 @@ pub fn num_cpus() -> uint {
     }
 }
 
-/// 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.
-#[cfg(target_os="macos")]
-pub fn limit_thread_creation_due_to_osx_and_valgrind() -> bool {
-    running_on_valgrind()
-}
-
-#[cfg(not(target_os="macos"))]
+/// 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 {
-    false
+    (cfg!(target_os="macos")) && running_on_valgrind()
 }
 
 /// Get's the number of scheduler threads requested by the environment