Git Product home page Git Product logo

num_threads's People

Contributors

aw-cf avatar complexspaces avatar ecnelises avatar freaky avatar jhpratt avatar photonquantum avatar thibault-ml avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

num_threads's Issues

Incorrect no. of threads in `x86_64-apple-darwin` targets run on Apple chips (M3 at least)

fn main() {
    assert_eq!(
        num_threads::num_threads(),
        std::num::NonZeroUsize::new(1)
    )
}
cargo run --target aarch64-apple-darwin               
   Compiling test-threadcount v1.0.0 (...)
    Finished dev [unoptimized + debuginfo] target(s) in 0.51s
     Running `target/aarch64-apple-darwin/debug/test-threadcount`
cargo run --target x86_64-apple-darwin                
   Compiling test-threadcount v1.0.0 (...)
    Finished dev [unoptimized + debuginfo] target(s) in 0.19s
     Running `target/x86_64-apple-darwin/debug/test-threadcount`
thread 'main' panicked at src/main.rs:2:5:
assertion `left == right` failed
  left: Some(2)
 right: Some(1)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

LLDB says it's 1 in both cases, which appears correct to me:

lldb target/x86_64-apple-darwin/debug/test-threadcount
(lldb) target create "target/x86_64-apple-darwin/debug/test-threadcount"
Current executable set to '.../target/x86_64-apple-darwin/debug/test-threadcount' (x86_64).
(lldb) break set --file src/main.rs --line 3
Breakpoint 1: where = test-threadcount`test_threadcount::main::h0b4a5b9d24100f68 + 11 at main.rs:3:9, address = 0x00000001000019ab
(lldb) run
Process 48950 launched: '.../target/x86_64-apple-darwin/debug/test-threadcount' (x86_64)
warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance.

Process 48950 stopped
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000019ab test-threadcount`test_threadcount::main::h0b4a5b9d24100f68 at main.rs:3:9
   1    fn main() {
   2        assert_eq!(
-> 3            num_threads::num_threads(),
   4            std::num::NonZeroUsize::new(1)
   5        )
   6    }
Target 0: (test-threadcount) stopped.
(lldb) thread list
Process 48950 stopped
* thread #1: tid = 0x2dfb06, 0x00000001000019ab test-threadcount`test_threadcount::main::h0b4a5b9d24100f68 at main.rs:3:9, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
(lldb) ^D
Project info
rustc --version
rustc 1.75.0 (82e1608df 2023-12-21)
cargo --version
cargo 1.75.0 (1d8b05cdd 2023-11-20)

Cargo.toml

[package]
name = "test-threadcount"
version = "1.0.0"

[dependencies]
num_threads = "0.1.6"

Cargo.lock

# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3

[[package]]
name = "libc"
version = "0.2.153"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9c198f91728a82281a64e1f4f9eeb25d82cb32a5de251c6bd1b5154d63a8e7bd"

[[package]]
name = "num_threads"
version = "0.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2819ce041d2ee131036f4fc9d6ae7ae125a3a40e97ba64d04fe799ad9dabbb44"
dependencies = [
 "libc",
]

[[package]]
name = "test-threadcount"
version = "1.0.0"
dependencies = [
 "num_threads",
]

Use `unshare` on Linux when you don't need the full count

From the man page unshare(2):

   In addition, CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM can be
   specified in flags if the caller is single threaded (i.e., it is
   not sharing its address space with another process or thread).
   In this case, these flags have no effect.  (Note also that
   specifying CLONE_THREAD automatically implies CLONE_VM, and
   specifying CLONE_VM automatically implies CLONE_SIGHAND.)  If the
   process is multithreaded, then the use of these flags results in
   an error.

cargo test fails due to other threads from cargo

Run cargo test on both x86_64-linux and aarch64-darwin:

running 2 tests
test test::is_single_threaded ... FAILED
test test::num_threads ... FAILED

failures:

---- test::is_single_threaded stdout ----
thread 'test::is_single_threaded' panicked at 'assertion failed: `(left == right)`
  left: `Some(false)`,
 right: `Some(true)`', src/lib.rs:56:13

---- test::num_threads stdout ----
thread 'test::num_threads' panicked at 'assertion failed: `(left == right)`
  left: `Some(3)`,
 right: `Some(1)`', src/lib.rs:44:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    test::is_single_threaded
    test::num_threads

Commenting out is_single_threaded, I'll see Some(2) from num_threads. So I guess that's because cargo or rustc has a main thread and the cases are executed in respective threads.

Can we specify RUST_TEST_THREADS=1 by some way in tests?

tests fail with Rust 1.67.0+

I'm maintaining the package for the num_threads crate in Fedora Linux, and i noticed that builds of the crate started to fail with Rust 1.67.0 due to failing tests:

     Running `/builddir/build/BUILD/num_threads-0.1.6/target/release/deps/num_threads-03ca46149c224543 --test-threads 1`
running 2 tests
test test::is_single_threaded ... FAILED
test test::num_threads ... FAILED
failures:
---- test::is_single_threaded stdout ----
thread 'test::is_single_threaded' panicked at 'assertion failed: `(left == right)`
  left: `Some(false)`,
 right: `Some(true)`', src/lib.rs:56:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- test::num_threads stdout ----
thread 'test::num_threads' panicked at 'assertion failed: `(left == right)`
  left: `Some(2)`,
 right: `Some(1)`', src/lib.rs:44:13
failures:
    test::is_single_threaded
    test::num_threads
test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass `--lib`

Is it possible that Rust 1.67.0 changed the way test runners work? It looks like there's one too much thread even when using -- --test-threads 1.

Memory leak in `num_threads::is_single_threaded()` on Apple platforms

The implementation for num_threads::is_single_threaded() is leaking thread_count mach ports on every call.

This is because thread_state is ignored currently. The correct usage of this API requires calling mach_port_deallocate and vm_deallocate. One example of using this API without leaking memory would be can be found here.

This issue was introduced with #6 (b12a1c8) and it could make sense to revert this change given fixing the current code would likely lead to more allocations/deallocations than the previous implementation.

Update the Rust version to compile on macOS

The current version of Rust being used to build is 1.28, which is nearly 5 years old.

This leads to libc not compiling on macOS in the tests.

We should look to update to a newer version, such as 1.76.0 (latest as of the writing of this ticket).

Use /proc/self/stat on Linux

Instead of walking every entry in /proc/self/task, would it not be better to read /proc/self/stat and parse field 20? proc(5):

          (20) num_threads  %ld
                 Number of threads in this process (since Linux
                 2.6).  Before kernel 2.6, this field was hard coded
                 to 0 as a placeholder for an earlier removed field.

Use /proc/self/task or /proc/self/status when /proc/self/stat returns 0

( follow-up to #3 )

in some weird cases, such as running qemu-user ( still debugging this issue ), /proc/self/stat returns mostly empty values, while /proc/self/task and /proc/self/status have the correct values:

$ cat /proc/self/stat
18477 (cat) R 16603 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 21552080 0 0 0 0 0 70368752569616 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
$ cat /proc/self/status | grep Thread
Threads:	2
$ ls /proc/self/task
18505  18507
$ 

it would be nice to have a fallback to those, in case they have correct values and /proc/self/stat doesn't

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.