Here’s my predicament: I have a large rust application with a bunch of tests, and many (if not most) of those tests spin up and then shut down one or more worker threads. Most of the interesting application logic happens on these other threads - so most interesting
println! statements that I might want to add don’t get captured in the current libtest test framework. Instead, all the output ends up going to stdout/stderr, regardless of whether the corresponding test succeeds or fails.
(Sidebar: Technically, I’m currently using slog and a lightly customized config that dumps to stderr - but I can easily redirect those messages to
println! to better conform to the existing libtest behavior of capturing
println!s but not stderr)
What I’d like to do, is provide some way of specifying or overriding the behavior to allow redirecting output of these worker threads into the buffer that libtest keeps for each test case.
I’ve dug a little bit into how
println! and libtest’s output capture interact via the undocumented
std::io::stdio::set_print function - and as far as I can tell, I don’t think this is possible, since I can’t get a handle on the
LOCAL_STDOUT for the current thread (the one that libstd overrode using set_print).
For the moment, I’d like to propose making solving this usecase possible, and maybe later look at what it takes to make this behavior clean/extensible/suitable for stabilization.
I think the bare minimum change to the standard library that would allow me to implement this myself is introducing a
get_print function, that just reads and returns
LOCAL_STDOUT (and corresponding
get_panic, because why not). Then, before I spawn these threads in my application, I can call
get_print to grab whatever the current one is, and the call
set_print in the “child” thread before doing any meaningful work.