These are chat archives for rust-lang/rust
x = 5on one thread and
x = 10on another thread, is it possible that the final result would ever be anything other than 5 or 10?
volatileback in the old days; it doesn't work, it may look like it works, and in is UB.
volatileis just qualifier used to declare that an object can be modified in program by another thread or something else
volatilecan be used for multithreading in languages such as Java and C#, but it has no such meaning in the C/C++ memory model, which is also the one that Rust is based on.
Utc::now().timestamp(). Are you making a system call to get the current time for every request? That will be where most of your time is being spent, and that is where you should point your attention if you really care about the efficiency of your rate limiter.
Arc<Mutex<(timestamp, HashMap<userId, (timestamp, tokens)>)>>
I didn't see that guide. You define structs and traits you need or import crates and then functionality like in other languages..
In the book is simple application: https://doc.rust-lang.org/stable/book/second-edition/ch20-00-final-project-a-web-server.html
But I think you want to use already some frameworks.. like tokio, actix etc.. depend what kind of application u wanna crate.
[src]button. Or just looking at how how the API looks like. But there's also a lot of links here (rust by example can be a good source). And there's this (I don't know why it is not linked anywhere) https://rust-lang-nursery.github.io/api-guidelines/
@rajasekarv First thing, are you running a release build? If so and you've got a faster (correct) implentation, you can of course open a merge request on the standard library. Or, even if you have a way that should be faster, but haven't written it yet, you can open an issue there describing it.
However, if you'd need to change the API (eg. offering two parsing methods instead of one), then that would need to go through the full RFC process (and changing behaviour of the current one would probably not be accepted, things are supposed to stay compatible).
Anyway, in general, if there's a balancing between correctness and speed, Rust first tries to do both and if that fails, prefers correctness in the place where people are going to reach for the thing first (and maybe offer alternatives as additional methods or something).
Well, quite a big possibility is that there's no rationale about it, that someone just did it at the early days and nobody touched it since.
But if there is a rationale and it was discussed, the place to look for the historical records would probably be either the RFC repository or the internals forum. Some discussion might have happened in the rust repo's issues as well, maybe.
If you find none, then assume the first possibility. Then you can open up the discussion ‒ probably in the internals forum.
arraymapis the only crate I know of that treats them directly. But to do this at all well you'd need to use macros, which is a bit finicky for a first project.