Function std::rt::util::limit_thread_creation_due_to_osx_and_valgrind

pub fn limit_thread_creation_due_to_osx_and_valgrind() -> bool

Unstable

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.