Tests do not set thread name when concurrency is disabled

[mitsuhiko]

Currently there are only workarounds for getting the test name from the current running test. The main one that people use is the thread name, but that does not work when tests are run with --test-threads=1.

I believe it would be beneficial to spawn a thread anyways so that the test name is discoverable. Alternatively — and maybe that's the better solution — there should be an API to discover the name of the current test.

[RalfJung]

I believe it would be beneficial to spawn a thread anyways so that the test name is discoverable.

This used to be how libtest operates. Unfortunately, that makes libtest not work in environments where threads cannot be spawned, such as Miri. That's why I made it not spawn threads when parallelism is disabled (#56243).

However, this could also be achieved by disabling threads on cfg(miri), editing this line:

rust/src/libtest/lib.rs

Line 470 in b76238a

let supports_threads = !cfg!(target_os = "emscripten") && !cfg!(target_arch = "wasm32");

We just try to keep uses of cfg(miri) to a minimum -- when Miri executes other code than "the real thing", we could easily miss UB.

Spawning a thread just to let tests get the test name seems quite awkward as well.^^

[Mark-Simulacrum]

Hm, can we perhaps set the thread name for the current thread? std doesn't provide a way to do it, but I know e.g. postgres does something like that.

In the multithreaded case, are we spawning a dedicated thread per test? That seems potentially quite costly, I would've expected some sort of thread pool (though likely without work stealing or anything fancy).

[RalfJung]

In the multithreaded case, are we spawning a dedicated thread per test?

I think so:

rust/src/libtest/lib.rs

Line 472 in b76238a

let cfg = thread::Builder::new().name(name.as_slice().to_owned());

[mitsuhiko]

@RalfJung

Hm, can we perhaps set the thread name for the current thread? std doesn't provide a way to do it, but I know e.g. postgres does something like that.

I think this generally would be a welcome addition to the stdlib. There does not seem to be a good reason why the thread name can't be changed after spawning.

[Mark-Simulacrum]

One challenge is that AFAICT, we are restricted to 15 characters in the naming of the thread; currently I believe libstd just ignores this -- the kernel will silently truncate I guess. "The thread name is a meaningful C language string, whose length is restricted to 16 characters, including the terminating null byte ('\0')." is from the manpage for pthread_setname_np which is what we use.

I'm not sure to what extent we care, but we'd probably at least want to put the trailing bytes (vs. the leading bytes), I think?

Or maybe this is all not actually a restriction because I can't recall seeing truncated names, just all the documentation alleges that it is...

[mitsuhiko]

I believe the right thing to do in general would be to expose a very rudimentary runtime API for tests.

[saethlin]

I've wanted this from time to time.

I think pthread_setname_np would let us do this on cfg(unix)? But for Windows it looks like there is only an API for this in Windows 10 and later. So I'm not sure what would be accepted here. Are we just condemned to wait for a long time because we can't do this portably? Could we do this on some platforms by sticking a #[cfg(unix)] function into libtest? I feel like this isn't desirable enough to add an unstable API to std that libtest then relies on, but I suppose that's a third option?

[RalfJung]

This is basically the same bug as #59122.

Miri supports threads nowadays, so from a Miri perspective we could revert #56243, which would also fix the thread name problem.