These are chat archives for rust-lang/rust

14th
May 2016
Daniel Collin
@emoon
May 14 2016 07:59
Anyone happens to know how to check if there is any data to read on a TcpStream? In C I would do it like this https://github.com/emoon/ProDBG/blob/master/api/src/remote/remote_connection.c#L62 Right now a read(…) call will block or is the only way to set a low time-out?
Vladimir Motylenko
@vldm
May 14 2016 09:07
@emoon rust std lib has only blocking IO, you can use mio for non-blocking IO. selectapi works on C preprocessor, so you can use C glue to process socket as RawFd. Or if you need only linux support, you can use unsafe code and poll`epoll` api. Another way is to spawn task for each socket.
Daniel Collin
@emoon
May 14 2016 09:09
@vldm alright. Thanks! It sounds like mio is the route to go then (as I need Windows support also)
nishidy
@nishidy
May 14 2016 09:31
Hi, is it Ok to think that Arc's clone() is something special in that it makes objects sharing the ownership of the reference? For String, the clone() method makes another value not sharing the ownership AFAIK.
In this example, the vec data is shared among threads but actually the same value (the element in vec) is not accessed by different thread.
But we can update the same element by some threads with mutex lock/unlock strategy, right?
Daniel Collin
@emoon
May 14 2016 09:35
This message was deleted
nishidy
@nishidy
May 14 2016 09:38
OK. In rust, we can force to lock/unlock strategy when we access the same value while other language like C allows us to do it without lock/unlock, which is not safe. Am I correct?
Daniel Collin
@emoon
May 14 2016 09:39
I’m not 100% sure but I think Arc is for immutable data only, you can’t mutate it. If you want mutation you need to use lock/unlock
"Arc<T> assumes one more property about its contents to ensure that it is safe to share across threads: it assumes its contents are Sync. This is true for our value if it's immutable, but we want to be able to mutate it, so we need something else to persuade the borrow checker we know what we're doing."
nishidy
@nishidy
May 14 2016 09:46
The correct implementation in the example is let data = Arc::new(Mutex::new(vec![1, 2, 3])); which is immutable. I think this is what you are saying that Arc is for immutable. Then, we can think that Mutex applies mutability for it? But this is hard to understand...
We can get the mutable reference from the immutable reference ??

use std::sync::{Arc, Mutex};
use std::thread;
use std::time::Duration;

fn main() {
let data = Arc::new(Mutex::new(vec![1, 2, 3]));

for i in 0..3 {
    let data = data.clone();
    thread::spawn(move || {
        let mut data = data.lock().unwrap();
        data[i] += 1;
    });
}

thread::sleep(Duration::from_millis(50));

}

let mut data = data.lock().unwrap();
This line seems to show my weird assumption to me
nishidy
@nishidy
May 14 2016 10:01
Maybe I can think that it is like to access some mutable fields of an object which immutable in OOP.
Vladimir Motylenko
@vldm
May 14 2016 10:02
@nishidy in rust thread::spawn, spawn thread that can outlive main thread, so you can only share 'static data. Arc, is a way, to ensure, that data will be valid as long as there is at least one Arc pointer is exist. In other word Arc, provide 'static + Send guarantee for shared data. But if you need modify data, you need synchronisation primitive, which will ensure that the data will only be changed in one place.
When you call lock() you get MutexGuard, and nobody can call lock() before your instantiation of MutexGuard will be dropped.
Sorry for my bad english.
nishidy
@nishidy
May 14 2016 10:18
No. it's good.
nishidy
@nishidy
May 14 2016 10:26
Arc exceptionally extends the lifetime until the counter becomes zero from not zero.
About Send trait, what do you think implements Send in this example?
impl<T> Send for Arc<T> where T: Send + Sync + ?Sized
impl<T> Sync for Arc<T> where T: Send + Sync + ?Sized
nishidy
@nishidy
May 14 2016 10:31
OK, Arc implements those.