These are chat archives for rust-lang/rust

25th
Jul 2017
David Harvey-Macaulay
@alteous
Jul 25 2017 02:54
To answer my own question (in case anyone is interested), it appears read() is blocking since the implementation calls libc::read which always blocks.
David Harvey-Macaulay
@alteous
Jul 25 2017 02:59
A non-blocking implementation might use the POSIX aio_* family of functions (or otherwise.)
Joonas Koivunen
@koivunej
Jul 25 2017 05:51
@RuRu92 yes, then you start getting into the problems i mentioned about the user account containing the accounts with the lock
@RuRu92 please always paste the related error you get. as you saw, it took me a while to guess which error you were getting...
RuRu92
@RuRu92
Jul 25 2017 08:07

@koivunej Is that a bad model to contain accounts with the lock on the user object?

Here is the playground, that should be a good way to show whats happening :)

Joonas Koivunen
@koivunej
Jul 25 2017 08:10
@RuRu92 i would say it is "bad" at this point in your program to create such fine-grained locks. a more coarse-grained would be something like a single lock over all users or all accounts. perhaps an even better design would be to avoid locks in such "domain models" at all costs, and do synchronization with a database
@RuRu92 the get_account(...) -> &Box<....> style API could be made to work, but that would probably require returning some type wrapping over the MutexGuard and the offset to read as the Mutex needs to be held locked while the &Box<...> is exists
RuRu92
@RuRu92
Jul 25 2017 08:14
@koivunej Hmm.. But lets say you have two threads running, one for the client and one for operations. I want to simulate the case where user account can decrease or increase randomly while performing operations himself on the account
I would need to synchronize the account access from different threads right?
Joonas Koivunen
@koivunej
Jul 25 2017 08:18
@RuRu92 yes, definetly some synchronization is required. it might be easier to start off with more coarse-grained locks (outside or around the domain objects, or User in your example)
@RuRu92 as in let mut me = Arc::new(Mutex::new(User::new(...)));... this would be somewhat analogous to a class in Java having synchronized in every method signature or using lock (this) { ... } in every method in C# (as I think I remember you mentioning either one of those languages earlier)
RuRu92
@RuRu92
Jul 25 2017 08:45

Yeah I come from Java background.

So in this case, I would model objects without any and arc + mutex vectors with sync/send and wrap them in Arc on initialization?

and when passing to threads I would lock the user and get this account data to manipulate?
Joonas Koivunen
@koivunej
Jul 25 2017 09:27
@RuRu92 yes, I would use Vec<X> instead of the Arc<Mutex<Vec<X>> inside the structs
@RuRu92 note that techically you'd lock the Mutex<User> which is owned by the Arc<Mutex<User>>. the Mutex<User>'s MutexGuard<'_, User> will let you access the User value as types in Rust do not have object monitor/mutex capabilities as they do have in Java/C#
lemonxah
@lemonxah
Jul 25 2017 09:41
hi, Just a sanity check but if you pass a Box<i32> into another function and return a new Box<i32> does the first one then get cleaned up?
Joonas Koivunen
@koivunej
Jul 25 2017 09:56
@lemonxah if the function is fn foo(_: Box<i32>) -> Box<i32> { Box::new(42) } I dont think there are any guarantees that memory is either deallocated (for the old box) and allocated (for the new box) or that it is not
lemonxah
@lemonxah
Jul 25 2017 10:05
lets say its Box<i32> -> Box<String>
Joonas Koivunen
@koivunej
Jul 25 2017 10:10
@lemonxah i don't think i'm qualified to speculate these further... if you were using some Box<MyType> which would implement Drop, I'd assume that cannot be optimized out. out of curiosity, what is the larger scheme you are thinking about?
lemonxah
@lemonxah
Jul 25 2017 10:11
i am having a hard time fixing my function to take a &Box<_> ( i am going to fix it) but then i just thought what would happen if instead of borrowing i just moved it
just idle curiosity
Joonas Koivunen
@koivunej
Jul 25 2017 10:12
@lemonxah this bug and it's related issues might be of interest if you want a deeper dive: rust-lang/rust#5016
@lemonxah what are your functions taking right now instead of &Box<_>?
lemonxah
@lemonxah
Jul 25 2017 10:13
Box<_>
but i will sort it out :) i am still learning rust so i must be doing something wrong
Joonas Koivunen
@koivunej
Jul 25 2017 10:14
@lemonxah i guess it'd be safe to assume that would mean a lot of deallocations and allocations which are very fast thanks to jemalloc
@lemonxah if you don't need to take ownership of the value (just to read it) a &X would be even better than &Box<X> as then the called functions wouldn't have to concern themselves with the implementation detail of whether Box is used or not
lemonxah
@lemonxah
Jul 25 2017 10:15
oh the reason it is Box<_> is because i am writing a functional lib
and making a monad
functor was easy since i could use &Box<_> just having a hard time with the output type at the moment
lemonxah
@lemonxah
Jul 25 2017 10:22
what kind of type is 'a ?
like
fn map<'a, A, B, F>(a: A, f: F) -> B where A: 'a, F: Fn(&'a A) -> B { f(a) }
Joonas Koivunen
@koivunej
Jul 25 2017 10:25
@lemonxah used in that context I believe it's an requirement that A must be fully self-contained struct A {...} // no borrowed data or it can contain borrowed data that will live at least for 'a
@lemonxah does that work? :)
lemonxah
@lemonxah
Jul 25 2017 10:26
what do you mean live for at least 'a
sorry i have no concept of this yet
but then &'a A does that mean that it should borrow something that lives at least 'a
let me try find documentation for lifetime maybe i will understand then
Joonas Koivunen
@koivunej
Jul 25 2017 10:28
aah ok, then 'a is a "lifetime", in the second edition book the first mention seems to be https://doc.rust-lang.org/book/second-edition/ch10-00-generics.html and first edition talks about it earlier i believe
Joonas Koivunen
@koivunej
Jul 25 2017 10:33
hmm I hadn't yet read the second edition on this subject and i like how the example is grown in the chapter, but the gist of lifetimes comes in the third section 10.3
lemonxah
@lemonxah
Jul 25 2017 10:35
cool thank you
Joonas Koivunen
@koivunej
Jul 25 2017 10:37
@lemonxah after that you probably want to check out the advanced lifetimes in 19.2 of the second edition
Joonas Koivunen
@koivunej
Jul 25 2017 10:42
have to say that the second-edition book gets better every time I open it (perhaps too rarely :D) ... the final project (simple http server) looks like a really good example.
stevensonmt
@stevensonmt
Jul 25 2017 13:16
ooohh. I didn't know the final project was added. It was still pending last I looked. Now I really need to finish working my way through the rest.
JD Gonzales
@juliusdelta
Jul 25 2017 19:11
Anyone know of any good testing resources/cheatsheet kind of thing for Rust?
Joonas Koivunen
@koivunej
Jul 25 2017 19:12
@juliusdelta there is a chapter on the book about it: https://doc.rust-lang.org/stable/book/second-edition/ch11-00-testing.html
JD Gonzales
@juliusdelta
Jul 25 2017 19:17
Thanks @koivunej