These are chat archives for rust-lang/rust

15th
Apr 2019
Denis Lisov
@tanriol
Apr 15 08:02
No idea what is Closure::wrap, but you probably need a separate clone of the Rc for the closure.
At least if you want to be able to access it from outside.
And it needs to be moved into the closure, so you need a move |_event: MouseEvent| closure
Aleksandr Lykhouzov
@lykhouzov
Apr 15 08:23
Thanks. i will try to do so...
Zakarum
@omni-viral
Apr 15 08:45
If there will be clone of the Rc then get_mut will return None and unwrap will panic.
Denis Lisov
@tanriol
Apr 15 09:24
...so it will need to be upgraded to a full Rc<RefCell<...>>
Akos Vandra
@axos88
Apr 15 15:34
How can I make this struct declaration work?
struct Challange<'a> {
  account: &'a Account,
  ....
}

pub struct X {
    account: Account,
    http_challange: Option<&'a Challenge>,
   (...)
}
Ingvar Stepanyan
@RReverser
Apr 15 15:35
X misses a lifetime
Akos Vandra
@axos88
Apr 15 15:35
Yeah, no
Ingvar Stepanyan
@RReverser
Apr 15 15:35
?
Akos Vandra
@axos88
Apr 15 15:35
As far as I see X shouldn't need a lifetime, because Option<&Challange> refers to a field of X
Ingvar Stepanyan
@RReverser
Apr 15 15:35
No, that doesn't work that way in Rust
Akos Vandra
@axos88
Apr 15 15:35
So the reference is guaranteed to live as long as X
*referred object
Ingvar Stepanyan
@RReverser
Apr 15 15:36
First of all, your &'a Challenge is just a reference - where is the actual challenge object?
Akos Vandra
@axos88
Apr 15 15:36
Is there something I'm missing, or is this a limitation of the compiler?
Ingvar Stepanyan
@RReverser
Apr 15 15:36
did you mean Option<Challenge<'a>> perhaps?
Akos Vandra
@axos88
Apr 15 15:37
oof.
:D
Ingvar Stepanyan
@RReverser
Apr 15 15:37
second, you still need a lifetime - it's not tied to data, but to the scope
imagine what happens when you e.g. return the X struct from a new method
it's getting actually moved somewhere, which invalidates any reference, because lifetime changes
that's why you can take lifetime only as a parameter
Akos Vandra
@axos88
Apr 15 15:39
:|
thanks
Ingvar Stepanyan
@RReverser
Apr 15 15:39
there are few ways to work around that, but they all involve using at least Box so that data is in a place that doesn't move
But in your case it seems easier to just make account owned inside Challenge?
Akos Vandra
@axos88
Apr 15 15:49
Problem is
that X needs to be 'static
and I Challange and Account comes from a library
And during the lifetime of X, it will create and destroy a few instances of accounts and challenges referring to said accounts
What I'm trying to achieve here is to wrap the acme-challange library into an actix actor
What is the workaround using Box? I'm still trying to get my head around the lifetimes of rust
Ingvar Stepanyan
@RReverser
Apr 15 15:53
Maybe look into something like rental https://docs.rs/rental/0.5.3/rental/macro.rental.html
It should help in your case
(you could do the same manually but it involves quite a bit of unsafe, and easy to get wrong in several ways; hence suggesting an existing wrapper)
Akos Vandra
@axos88
Apr 15 15:59
thanks, I'll look into this,
Denis Lisov
@tanriol
Apr 15 16:53
What's the library you're wrapping?
Victor Lopes
@vlopes11
Apr 15 18:14
Hello Rustaceans. Is it possible to have a method / function return a reference to some data owned by a RwLock/Mutex/etc? Something like this:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=3e0c31505746f40a0461001f7272689c
use std::sync::{Arc, RwLock};

struct SomeStruct {}

struct SomeOwner {
    child: Arc<RwLock<SomeStruct>>
}

impl SomeOwner {
    pub fn new() -> Self {
        let some = SomeStruct {};
        let child = Arc::new(RwLock::new(some));
        SomeOwner {
            child,
        }
    }

    pub fn get_child(&self) -> &SomeStruct {
        &self.child.try_read().unwrap()
    }
}

fn main() {
}
I understand the reference have temporary scope owned by get_child; therefore, as I see, it's not possible to refer this child, only to own it (via clone or whatever)
Denis Lisov
@tanriol
Apr 15 18:16
What do you expect to happen if someone calls that function and gets that reference, and after that replaces that data inside the RwLock with something else? ;-)
Victor Lopes
@vlopes11
Apr 15 18:17
It's the standard race condition, I understand
But it's tricky if I have to keep cloning this data all the time
Denis Lisov
@tanriol
Apr 15 18:18
Is your problem performance or something else? What kind of data is that?
Victor Lopes
@vlopes11
Apr 15 18:19
The thing is this struct is always immutable, and hold only some information (Strings, numbers, etc). Therefore, the race condition will never happen
Of course this ain't a "big" performance issue, but I see no way to avoid the copying of the data here
Denis Lisov
@tanriol
Apr 15 18:20
Then why do you actually need an RwLock? :-)
Victor Lopes
@vlopes11
Apr 15 18:20
To share the same reference among different threads. Otherwise I would have to move the ownership
Maybe only one arc would be enough, but this is not atomic
I could serialize into bytes, dunno
Denis Lisov
@tanriol
Apr 15 18:21
You don't need it to be atomic if it never changes...
Victor Lopes
@vlopes11
Apr 15 18:21
Omg lol. Ok I'll test
Denis Lisov
@tanriol
Apr 15 18:22
You could read not whole structures, but just the fields you need - they're likely small enough for their copying to be insignificant.
Victor Lopes
@vlopes11
Apr 15 18:23
Yeah it works! Thanks man. I was totally stuck into the idea that Arc holds only atomic types lol
Denis Lisov
@tanriol
Apr 15 18:23
You could do something like owner.run_with_config(|config| do_the_processing_that_needs_config(config))
Victor Lopes
@vlopes11
Apr 15 18:25
Yep, everything works. It's weird I didn't consider the Arc would be smart to consider as atomic every never-mutable structs. Thanks again, bro :D
ozgurakkurt
@ozgurakkurt
Apr 15 20:47
Hi, does any one know a way to use the value of target-cpu flag like #[cfg(target_cpu="skylake")]
Denis Lisov
@tanriol
Apr 15 21:05
What do you mean? Getting it as a string?