I understand the two statements above in the article, just not how they can be made to work in this case. Apologies again if this is an obvious question, as I was saying I am definitely just starting out in rust.
I understand the two statements above in the article, just not how they can be made to work in this case. Apologies again if this is an obvious question, as I was saying I am definitely just starting out in rust.
Hopefully that gets the gist of how you might approach it. I'm not sure I'd use the HashSet myself, to be completely honest, because it makes it needlessly complicated to get an element out of it. I'd probably just use a Vec.
I don’t find a strong case for using Rust just to guarantee each thread gets its own IP (a mutex protected getter seems like it would do just fine for just that) but I guess it would guarantee that as long as you use this “uncopiable” object you could not, even if you wanted to, have two identical IPs in your program if I understand things correctly, which if your mutex getter had a bug would not protect you against.
I think that mutex are actually a really good example of what he's talking about in the article. You can only access the data from a Rust mutex through a `MutexGuard` returned from the lock method. `MutexGuard` is uncloneable and therefore, when it is dropped at the end of its scope, the mutex knows that it is free and can automatically unlock it. Additionally, it is impossible to access the data without having the `MutexGuard`, so you can statically determine at compile time that all data access is behind a lock.