Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a shared vision for Async Rust

blog.rust-lang.org

Post reply on HN
Print view View original

111–120 of 139 posts

Re: Building a shared vision for Async Rust

#111

Post by ori_b »

cycloptic wrote: post #108
ori_b wrote: post #91

Earlier quoted context omitted.

Yield points in the middle of a large matrix multiplication (for example)? Manually scheduling threads seems like a really shitty way to program

Not really? That's cooperative multitasking and it's used a lot: https://en.wikipedia.org/wiki/Cooperative_multitasking But regardless, the GP post was not taking about matrix math, it seems it was talking about sending an HTTP request and waiting for a response, which is something that actually is I/O bound on the TCP socket.

I know what it is, and there's a reason that all the systems listed as using it are obsolete.

> "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy."

Strongly implies to me that there's a CPU-bound component there.

Re: Building a shared vision for Async Rust

#112

Post by pas »

millstone wrote: post #83
adwn wrote: post #79

Earlier quoted context omitted.

> I agree. In Rust I write correct code slowly. "Productive" I am not. I'm confused by that statement. Do you not care whether your code works correctly? Do you consider finding and fixing bugs to be separate from writing code?

Rust has lots of nonsense with zero practical benefit. Examples: PhantomData, higher-ranked trait bounds, "upstream crates may add a new impl". I have satisfied the compiler but no bugs were prevented. It's just busywork.

You don't have to use PhantomData.

> "upstream crates may add a new impl" I have satisfied the compiler but no bugs were prevented.

Trial-and-error debugging which version causes a bug is busywork, preventing it right when someone introduces the potential problem is at best annoying, but very fast compared to the alternative.

Re: Building a shared vision for Async Rust

#113

Post by pas »

millstone wrote: post #75
rng_civ wrote: post #72

Earlier quoted context omitted.

> But WASM is already sandboxed Sandboxing only secures the boundary between the WASM interpreter and the embedding application (typically the browser). You can still perform significant exploits within the sandbox. See [0] IIRC, low-level languages need to maintain a shadow stack in the heap because WASM has no native support for stack variable pointers and without ASLR, we're inching dangerously close to classic bu…

Sorry but that's baloney. Web developers are not choosing Rust/WASM because of security concerns with C++/WASM. The whole point of WASM is to enable untrusted code. Instead I believe they are choosing Rust/WASM because of the Rust ecosystem: familiar package management, tutorials, other resources.

> whole point of WASM is to enable untrusted code.

... ?

The web is already full of untrusted JS. WASM is for performance. The added extra security is just the cherry on top.

Re: Building a shared vision for Async Rust

#114

Post by scoutt »

steveklabnik wrote: post #99
scoutt wrote: post #84

We poor embedded developers are always forgotten :( Grace, the only C/C++ dev, does stuff like "Grace has already decided to use a thread-per-core model and minimize cross-thread communication".

In what sense? Your opinions would be wanted here too!

Don't worry. I've just started to explore Rust (coming from 20 years of embedded C). I was just sad I didn't see bare-metal represented in the examples and status-quo stories.

Re: Building a shared vision for Async Rust

#115

Post by steveklabnik »

scoutt wrote: post #114
steveklabnik wrote: post #99

Earlier quoted context omitted.

In what sense? Your opinions would be wanted here too!

Don't worry. I've just started to explore Rust (coming from 20 years of embedded C). I was just sad I didn't see bare-metal represented in the examples and status-quo stories.

Ah. We took it into account when building async generally, but it hasn't gotten as much actual usage as folks doing networking, so that's probably why it was overlooked. I'll make sure to ping them about it though... I myself am very interested in this case :)

Re: Building a shared vision for Async Rust

#116

Post by cycloptic »

ori_b wrote: post #111
cycloptic wrote: post #108

Earlier quoted context omitted.

Not really? That's cooperative multitasking and it's used a lot: https://en.wikipedia.org/wiki/Cooperative_multitasking But regardless, the GP post was not taking about matrix math, it seems it was talking about sending an HTTP request and waiting for a response, which is something that actually is I/O bound on the TCP socket.

I know what it is, and there's a reason that all the systems listed as using it are obsolete. > "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy." Strongly implies to me that there's a CPU-bound component there.

The systems that use it as a native threading model are obsolete, but there's also this sentence there:

>Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python.

There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread for an HTTP request to return, that's never going to be CPU-bound. I still am failing to see what the problem here is besides a complaint about some rust crate only supporting a multi-threaded executor, which again is a different problem than whether it's done with async futures or not. One could just as easily write some C code that forces the use of threads.

Re: Building a shared vision for Async Rust

#117

Post by cycloptic »

AgalmicVentures wrote: post #96
woah wrote: post #87

Earlier quoted context omitted.

Doesn’t matter who he is, if he’s mad that libraries made for and by web and network developers are using a concurrency model that works well for their applications, he should use different libraries.

It does matter -- he was one of the first "network developers". He published RFC 896 over 35 years ago; he has more experience on this topic than almost anyone. > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. This is not the strongest plausible interpretation of what he said -- He's not asking for people to not develop as…

>If you're expecting a blocking system call, and actually get a brand new background thread that's polling, it's quite reasonable to be frustrated.

It really isn't if the documentation doesn't outright say that it's single threaded and not thread safe. For a lot of simpler use cases where you just want to ship a thread-safe API (e.g. application does not have its own thread pool) then it just makes sense in a lot of cases to use some kind of automatic thread pooling. The caller does not have to know or care how the internal state machine is implemented.

If you have implemented your own thread pool it seems you should know enough to dig down enough to the lower layers to where you can get to that blocking syscall, or least to the point where you can strip off the O_NONBLOCK flags yourself.

Re: Building a shared vision for Async Rust

#118

Post by stormbrew »

steveklabnik wrote: post #98
stormbrew wrote: post #48

Earlier quoted context omitted.

I really really hope this never ever happens. Tokio is great and all, but enshrining it as the default would have a stifling effect and impose a lot of design decisions all over the place. I do hope that it becomes more possible to write async code that is portable between executors. If there were more standard traits around the most common elements of an executor it'd make things a lot better imo.

It wasn't suggested that it be Tokio, it was suggested that it be a minimal one, that could get you started without needing to make big choices before you even begin. (And yes, portability would have to be a part of that story.)

I took the post mentioning the de-facto normalization of tokio as implying that the default could be tokio, or at least based on tokio. Maybe I misinterpreted, but that was my reading of the post I was replying to.

That said, I think no matter how minimal it is it would still be a mistake. If anything, I think the only thing that would make sense to include is basically a "not-really-async" executor to appease things like the sibling thread where people want to be able to incorporate async code into their sync codebase without spawning a reactor thread. But that would also require the ability to genericize libraries over executors (and would obviously come with some significant caveats around potential deadlocks).

Re: Building a shared vision for Async Rust

#119

Post by [deleted] »

cycloptic wrote: post #116
ori_b wrote: post #111

Earlier quoted context omitted.

I know what it is, and there's a reason that all the systems listed as using it are obsolete. > "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy." Strongly implies to me that there's a CPU-bound component there.

The systems that use it as a native threading model are obsolete, but there's also this sentence there: >Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python. There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread…

[deleted]

Re: Building a shared vision for Async Rust

#120

Post by ori_b »

cycloptic wrote: post #116
ori_b wrote: post #111

Earlier quoted context omitted.

I know what it is, and there's a reason that all the systems listed as using it are obsolete. > "I don't want an async model, which assumes you're I/O bound, interfering with keeping all those CPUs busy." Strongly implies to me that there's a CPU-bound component there.

The systems that use it as a native threading model are obsolete, but there's also this sentence there: >Cooperative multitasking is used with await in languages with a single-threaded event-loop in their runtime, like JavaScript or Python. There's no reason rust can't have an executor that does the same, and you only use that within the event loop on your one or two HTTP worker threads. If you're waiting in a thread…

Those languages are also well known for not handling multiple cpu bound threads well. (And for that matter, it's simply wrong about Python, which uses native threads, but locks very heavily: you need to write native code to use more than one core effectively from one process.)

The goal is to NOT do what you're suggesting. It's a holdover from when native threads were much more expensive than they are today, and multiple cores on a single cpu were rare.

Post reply on HN