carllerche

9 ms·

61.
by carllerche 6y ago
We are definitely exploring this as well. There are a few possible ways to move forward on this. I'm not sure which is best yet, but with 1.0 out, we are going to be able to put more time into it.
62.
Tokio 1.0 – async runtime for Rust(tokio.rs)
769 points by carllerche 6y ago|402 comments
63.
by carllerche 6y ago
The article called out 500usec as an upper bound for compute. How do you handle heavier compute operations (TlS, encoding / decoding, ...)
64.
Why AWS loves Rust, and how we’d like to help(aws.amazon.com)
492 points by carllerche 6y ago|325 comments
65.
by carllerche 6y ago
We are still figuring that out. When I wrote that post, uring was not yet working with sockets. Things have changed. We are exploring the space.
66.
by carllerche 6y ago
The model is very similar to how epoll works. The executor does not poll futures in a loop. Between polls, the executor waits for a readiness notification. If `Future::poll` returns Pending, once it becomes ready to do more work, it notifie
67.
by carllerche 6y ago
You aren't wrong. In hindsight, we should have shipped 1.0 a year or so after v0.1. I don't think we can ship 2.0 now . v0.3 is going to happen soon to fix errors in v0.2. async/await in Rust is very new. We are still fig
68.
by carllerche 6y ago
Great question. I'm not thinking about competing. All I care about is users and building a great library. I think the best way to advance the state of the ecosystem is by experimenting and shipping improvements. IMO Ideas are best shar
69.
by carllerche 6y ago
We're aiming for 1.0 by Q3 2020. I wrote a bit about it here: https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0 That said, io_uring may end up impacting that target by a little bit. I understand t
70.
by carllerche 6y ago
It gets better every day. async/await is relatively new (stabilized end of last year). All the misc libs in the Tokio stack have been updated. There is Tonic for gRPC, Hyper/reqwest/warp for HTTP, ... these all work with asyn
71.
by carllerche 6y ago
Tokio should not add any overhead compared to writing an equivalent by hand with no abstractions. I'm a programmer, not a marketer :) Happy to take suggestions on the copy.
72.
by carllerche 6y ago
Hi! Tokio maintainer here. I'm surprised (in a good way) to see this posted to HN today. Nothing big is happening this week. That said, I'm always happy to answer questions.
73.
Mini-redis: A Redis server implementation using Rust and Tokio(github.com)
2 points by carllerche 6y ago|0 comments
74.
Reducing tail latencies in async Rust applications with automatic task yielding(tokio.rs)
2 points by carllerche 7y ago|0 comments
75.
by carllerche 7y ago
Tokio author here (mentioned in blog post). It is really great to see these success stories. I also think it is great that Discord is using the right tool for the job. It isn't often that you need the performance gains that Rust &amp
76.
by carllerche 7y ago
As an OSS author, unless I ask for that feedback, “me too” comments both add noise to my inbox and come off as entitled. It feels like the author of the comment expects me to implement a feature for them because they want it. I don’t mainta
77.
by carllerche 7y ago
I skimmed the paper and it looks similar to loom. Specifically they cite CHESS and Cdschecker as prior art. Both of those are what loom is based on. I guess 2019 is the year of concurrency checking :-)
78.
by carllerche 7y ago
Last time I spoke about this topic w/ the rust compiler devs, they mentioned there were some LLVM "bugs" with regards to optimizations and Relaxed, as in LLVM is too conservative.
79.
by carllerche 7y ago
To be honest, I'm not entirely following what you see as the danger. The compiler can't generate code that randomly goes and writes at pointer locations.
80.
by carllerche 7y ago
Right now, CPU intensive code blocks or code blocks that block need to be annotated. This way, the scheduler can respond accordingly (cooperative).
81.
by carllerche 7y ago
> Did you consider work sharing or work requesting instead of work stealing Not really. It did cross my mind for a moment, but my gut (which is often wrong) is the latency needed to request would be much higher than what is needed to ste
82.
by carllerche 7y ago
I believe there are some LLVM "bugs" with regards to Relaxed ordering. I don't know the specifics.
83.
by carllerche 7y ago
The Tokio scheduler uses cooperative multitasking (non-preemptive). So, if your task runs without yielding it can prevent other runnable tasks from executing. So, if that is acceptable, then it is fine.
84.
by carllerche 7y ago
I saw your edit. Your summary of why `Relaxed` matches my reasoning. The code should probably be switched to `Relaxed`.
85.
by carllerche 7y ago
Ah thanks! You are correct! Perhaps you should also review the PR? (a tiny bit longer) :)
86.
by carllerche 7y ago
The expectation is that all code running on the Tokio scheduler does not block and does not do anything CPU intensive. There is follow up work planned to allow annotating blocking / CPU intensive bits of code so that the scheduler can
87.
by carllerche 7y ago
Thanks, I appreciate it! The new scheduler will still require using a special API to run CPU intensive futures: `tokio_executor::blocking::run(|| cpu_intensive())`
88.
by carllerche 7y ago
Thanks! I appreciate it.
89.
by carllerche 7y ago
The compiler cannot use the contents of an `UnsafeCell` for temporary storage. In general, `UnsafeCell` is how data can be shared across threads without synchronization.
90.
by carllerche 7y ago
The Hyper benchmark uses multiple threads. When I ran the benchmark, I modified the version found in Hyper's github to use both the old multi-threaded scheduler and the new multi-threaded scheduler. I probably should make that clear in

More ›