recv() cpu abuse

[h04x]

Hello. I'm new with Rust. 20 recv() uses 40% cpu on my linux box. Is this a known issue?

extern crate bus;
use bus::Bus;
use std::sync::{Arc, Mutex};
use std::thread;
use std::io;


fn main() {
    let bus: std::sync::Arc<std::sync::Mutex<bus::Bus<usize>>>
        = Arc::new(Mutex::new(Bus::new(10)));

    for _ in 0..20 {
        let mut rxb = bus.clone().lock().unwrap().add_rx();
        thread::spawn(move || loop {
            let msg = rxb.recv().unwrap();
        });
    }

    io::stdin().read_line(&mut String::new()).unwrap();
}

total

11909 root      20   0 1029148   1980   1700 S  39.2   0.1   1:01.07 bus_possible_bu

per thread

11926 root      20   0 1029148   1980   1700 R   2.7   0.1   0:00.19 bus_possible_bu
11927 root      20   0 1029148   1980   1700 R   2.7   0.1   0:00.19 bus_possible_bu
11931 root      20   0 1029148   1980   1700 R   2.7   0.1   0:00.19 bus_possible_bu

cpu

model name      : Intel(R) Core(TM) i3 CPU         540  @ 3.07GHz

[jonhoo]

Ah, yes, those idle cycles stem from

bus/src/lib.rs

Line 405 in ec317a2

thread::park_timeout(spintime);

. There is at least one case where the readers race with the writer and may not successfully wake it up, so the writer has to park with a timeout. I would love to get rid of this, but haven't had a chance to dig into it, and no longer use this library actively myself. If you want to take a look, I'd be happy to help out!

[xixixao]

@jonhoo Would be great to note this problem in the README. With this problem the crate isn't exactly "Efficient". Perhaps suggest an alternative if this crate is no longer maintained.

I like its API, so thanks for putting it up!

[jonhoo]

@xixixao Would you be up for writing up a quick PR that adds this note to the README? Seems completely reasonable to me 👍

[metasim]

If anyone has ideas on how to patch/fix this, I'd be interested in helping explore solutions. I moved from ZeroMQ pub-sub to bus to eliminate serialization, and I really like the ergonomics of bus, but am running in a resource constrained "edge" environment where burning cpu cycles actually has operational implications.