carllerche

Interesting, could you elaborate on what you mean by "shared mutable state"? In the parse_line example (first one in the post), what state is shared and with whom is it shared?

I believe it would be possible to implement using an edition in a way that any *old* code is compatible with new code.

Regarding implicitness, a lot in Rust already is implicit (e.g. type inference). Good implicitness only feels weird at first, before we get used to it. I linked to Aaron Turon's article on reasoning footprint, but as a follow up, there is withoutboat's article on "not explicit" that goes into the topic more: https://boats.gitlab.io/blog/post/2017-12-27-things-explicit...

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.

The article called out 500usec as an upper bound for compute. How do you handle heavier compute operations (TlS, encoding / decoding, ...)

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.

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 notifies the executor, the executor then schedules the future to be polled again.

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 figuring things out.

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 shared as working code.

The Tokio team has been very active on that front. Recently, we've shipped a new strategy to improve the cooperative scheduler (https://tokio.rs/blog/2020-04-preemption/), and a bunch of other new utilities (https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12, https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11).

Standardization can be extracted once proven. This is how `std::future` came to be.

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 the sentiment re v1. In reality, Tokio v0.1 was pretty much 1.0. We never cut 1.0 because async/await was in the works and it was unclear when it would be released. Now that async/await is out, 0.2 was a big change. We need some time to stabilize our APIs and collect user feedback. This process is happening now and going well.

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 async/await now.

For docs, there are some now and I expect it to improve a lot throughout the year.

We also just posted mini-redis as a larger "real world" example: https://github.com/tokio-rs/mini-redis

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.

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.

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 & Tokio so pick what works best to get the job done and iterate.

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 maintain OSS as a product, I maintain it because it is code that I need for my personal use cases and I benefit by having others participate in QA and feature dev.

This probably does not apply to OSS projects that are products built by companies.

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 :-)

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.

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.

Right now, CPU intensive code blocks or code blocks that block need to be annotated. This way, the scheduler can respond accordingly (cooperative).

> 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 steal. I probably should test it though at some point :)

> assuming this is rare enough, an expensive last resort work stealing

It's not _that_ rare. Stealing is key when a large batch of tasks arrive (usually after a call to `epoll_wait`). Again, I have no numbers to back any of this :)

I believe there are some LLVM "bugs" with regards to Relaxed ordering. I don't know the specifics.

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.

I saw your edit. Your summary of why `Relaxed` matches my reasoning. The code should probably be switched to `Relaxed`.

Ah thanks! You are correct! Perhaps you should also review the PR? (a tiny bit longer) :)

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 do something smarter (things like you linked).

The old scheduler already had such an annotation, but in the interest of shipping, this has punted in the new scheduler.

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())`

Thanks! I appreciate it.

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.

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 the article.

Assuming [this](https://github.com/fastflow/fastflow/blob/master/ff/buffer.h...) is the FFBuffer in question, it looks like it is spsc (which would not support stealing). Also, it would need some kind of synchronization to ensure consistency between the consumer & producer.

Yes! Rayon is the perfect use case for the Chase-Lev queue!