231–236 of 236 posts
Earlier quoted context omitted.
Tokio does sync I/O in the background with dedicated I/O threads if memory serves. (it is sync in the sense it does syscalls, which are pushed to a dedicated thread).
Only for file access, which wasn't supported by async on Linux until io-uring.
Earlier quoted context omitted.
Only for file access, which wasn't supported by async on Linux until io-uring.
No, any spawn_blocking will run on its own dedicated thread
(Your response isn't entirely accurate though: it's using a thread pool whose size is configurable, not one thread per spaw_blocking)
Earlier quoted context omitted.
The complexity of this code snippet almost seems satirical (though I do get the point you're making, and agree with you).
On one hand, I agree that on the surface, this looks complex, if you don't read it. But on the other hand, just read the code. It's not complex. You drill down into a tokio namespace. You make a builder object. You unwrap it. This is idiomatic Rust. It's verbose, but explicit is better than vague. There's no conditional logic. There's no weird type-fu. No macros. There's not even any parameters to supply, other than…
Earlier quoted context omitted.
I think async is still in the more just trendy camp than being a proven asset. After all, thread per connection is perfectly viable for the vast majority of servers. Most people aren't re-writing NGINX, after all (hopefully...). It's a shame Rust let itself be distracted by it instead of focusing on refining its strengths and developer experience
> Most people aren't re-writing NGINX, after all (hopefully...). those people probably may use another language (java, go, c#) if absolute performance is not critical for them.
I think std needs a default runtime, and we might as well make it tokio, but maybe make the single-threaded executor the default instead and tweak the API where appropriate to align with this change. Swapping the executors out should absolutely be a feature, and the traits should be portable, but a way to start fixing the situation beyond the great suggestions in this proposal is to acknowledge that std and no-std us…
I believe that without.boats (or somebody of similar prominence) proposed that pollster ( https://docs.rs/pollster/latest/pollster/ ) or a similar async executor be pulled into std. I think it's a great idea. By blessing something that's not tokio you give a good incentive for library authors to test against more than one executor. And by being so far from fully featured pollster is never going to "win" so blessing i…
Earlier quoted context omitted.
Another instance of a trivial and obvious feature that can only really be designed one way that is not implemented 4 years after initial proposal.
I am not fully sure I agree with the first part of your assessment, but I share the frustration that a feature like this, which would be useful and is not particularly large, is basically ignored by the working group, while larger, more controversial, and less useful features, like keyword generics, are pursued while the more useful things languish.