Async-await on stable Rust • Hacker News Board

Re: Async-await on stable Rust

#161

Post by pas » Thu, Nov 07, 2019, 6:16 PM UTC

phamilton wrote: post #141

bluejekyll wrote: post #138

Earlier quoted context omitted.

No, but if that library claims to be an async library, wouldn't that be a bug in the library? Edit: I'm interpreting your use of sync here as "blocking" and not as Sync in Rust, meaning safe to share across threads. To be clear in my initial response I was talking about shared memory across threads, and may have misunderstood your original statement.

Yes. And I want the language to use types and compilers to eliminate that whole class of bugs.

Static analysis should help with this. Basically it should identify every call site where I/O happens (and other syscalls), and then you have to check them that they are invoked with the right async/nonblocking dance.

This is basically a code audit problem.

Of course something like taint analysis could also work. Every such callsite should be counted as tainted unless it gets wrapped with something that's whitelisted (or uses the right marker type wrapper).

Even effects as types can't help much, because the basic interfere to the kernels (Linux, WinNT, etc.) are not typesafe, and as long as the language provides FFI/syscall interfaces you have to audit/trust the codebase/ecosystem.

Re: Async-await on stable Rust

#162

Post by pas » Thu, Nov 07, 2019, 6:19 PM UTC

mamcx wrote: post #151

nemothekid wrote: post #131

Earlier quoted context omitted.

Both actix and reqwest are already async, the fact that you haven't noticed yet just shows that you are already ignoring it.

But the signatures are not. If them mark the types/functions async, what happened? I must rewrite all the calls?

Async is just a syntactic sugar for Future, you can poll() it manually.

You can take the event loop, run it on one thread and do whatever you wish on other threads.

Fearless concurrency, after all.

Re: Async-await on stable Rust

#163

Post by leshow » Thu, Nov 07, 2019, 6:20 PM UTC

phamilton wrote: post #147

bryanlarsen wrote: post #144

Earlier quoted context omitted.

Whether a function is async-safe isn't black and white. A function that performs calculations may return instantly on a small dataset but block for "too long" on large parameters. On what is "too long" will vary widely depending on your application.

But whether a function is not async-safe is pretty black and white (i.e. there's a lot of clearly unsafe code). Even a definition as simple as "performs blocking I/O" would be extremely helpful. This is the value people get out of async only environments like node. Yes, you still have to worry about costly for loops but I don't have to worry about which database driver I'm using because they are all async. In a mixed…

There are plenty of synchronous calls in node and js. Not everything is async https://nodejs.org/api/fs.html#fs_dir_readsync

And that's just io, most function calls are synchronous also

Re: Async-await on stable Rust

#164

Post by esotericn » Thu, Nov 07, 2019, 6:25 PM UTC

dunkelheit wrote: post #122

entropicdrifter wrote: post #63

Earlier quoted context omitted.

Couldn't you just pass in the (other) borrowed field as an argument for the function? If you need it to work without adding the argument when called outside of the class, you could overload it with a version that borrows the field and passes it to the version that takes the field as an argument, right? I'm newish to Rust, so this is just an intuitive guess. Please let me know if I'm wrong.

Yes, it works, but feels unnatural. I also don't like the possibility (quite remote, I admit) that the function gets called with a field from another instance.

The latter case should be impossible if the method is private?

Re: Async-await on stable Rust

#165

Post by unlinked_dll » Thu, Nov 07, 2019, 6:29 PM UTC

bullen wrote: post #86

littlestymaar wrote: post #56

Earlier quoted context omitted.

What do you mean by “on the same memory” exactly? If you want two threads running in parallel to concurrently access the same memory location you don't need synchronization if you only perform reads, and you need one if there is at least one write. Like in any other language (this comes directly from how CPU works). The good thing with Rust is that you can't shoot yourself in the foot: if you can't accidentally have…

I mean just like it reads: I want two (or more) threads to write the same memory at the same time. This is a problem Java "solved"/"worked around" with a complete memory model rewrite for the whole JDK and the concurrency package in 2004 (1.5). The solutions range from mutexes to copy-on-write and more.

you can use whatever synchronization techniques you want, from lock free data structures/queues, to mutexes, to unadulterated unsafe reads/writes to raw pointers.

std provides some useful helpers like Arc and Mutex (Arc> is always safe to use across threads, as the lifetime is managed safely by Arc and accesses handled by Mutex).

There are crates out there for things like lock free sync and other GC if you need it. Rust doesn't force you into a single world view.

Re: Async-await on stable Rust

#166

Post by nicoburns » Thu, Nov 07, 2019, 6:30 PM UTC

phamilton wrote: post #147

bryanlarsen wrote: post #144

Earlier quoted context omitted.

Whether a function is async-safe isn't black and white. A function that performs calculations may return instantly on a small dataset but block for "too long" on large parameters. On what is "too long" will vary widely depending on your application.

But whether a function is not async-safe is pretty black and white (i.e. there's a lot of clearly unsafe code). Even a definition as simple as "performs blocking I/O" would be extremely helpful. This is the value people get out of async only environments like node. Yes, you still have to worry about costly for loops but I don't have to worry about which database driver I'm using because they are all async. In a mixed…

What about long-running computations? They're not really async-safe (they will block the thread), but they don't perform any IO.

Re: Async-await on stable Rust

#167

Post by leshow » Thu, Nov 07, 2019, 6:35 PM UTC

ralusek wrote: post #30

Isn't it kind of a poor design choice that Rust will not actually begin execution of the function until `.await` is called? If I didn't want to execute the function yet, I wouldn't have invoked it. Awaiting is a completely different concept than invoking, why overload it? If you want to defer execution of a promise until you await it, you can always do that, but this paradigm forces you to do that. The problem is the…

Note that your first promise doesn't actually do anything in parallel. It just schedules all of those tasks at once. Execution will still be concurrent.

Re: Async-await on stable Rust

#168

Post by pixel_fcker » Thu, Nov 07, 2019, 6:36 PM UTC

eeZah7Ux wrote: post #143

The level of fanboyism in the comments is saddening. Many other fast and productive languages have async since a while.

Or maybe there are just a lot of people who like using rust because it fits their use cases very well and are excited about the release of a big new feature that’s been in development for a long time?

Re: Async-await on stable Rust

#169

Post by bernawil » Thu, Nov 07, 2019, 6:38 PM UTC

jayd16 wrote: post #116

fooyc wrote: post #98

This is a big improvement, however this is still explicit/userland asynchronous programming: If anything down the callstack is synchronous, it blocks everything. This requires every components of a program, including every dependency, to be specifically designed for this kind of concurency. Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything a…

Isn't this the most convenient setup though? I'm most familiar with async/await in UI programming and you most often have a main thread for synchronization. You want to assume that most of your main thread work is synchronous and non-yielding until you explicitly yield. Seems like it would be a lot harder to use main thread synchronization in the style your suggesting. Maybe I just can't imagine it. Whats a good lang…

>Whats a good language that shows off the style you're suggesting? javascript.

What you describe sounds like native UI work since forever before javascript. "Don't block the main thread" and all that.

Javascript is diferent in that it's a single-thread with an event loop. Synchronous functions execute until they end. Asynchronous functions are handled by the event loop which "loops" between the pool and runs each one for some time, then switches to other, concurrenly (think round robin). What happens when the runtime is running an asynchronous function and inside it reaches a synchronous one? it stops round-robin and executes this function until it ends.

What OP wants is a language like javascript but without having to write code distinguishing synchronous and asynchronous functions and instead having some other tool to tell the runtime when a function is synchronous or asynchronous without having to write it again.

Re: Async-await on stable Rust

#170

Post by harikb » Thu, Nov 07, 2019, 6:43 PM UTC

littlestymaar wrote: post #127

fooyc wrote: post #98

This is a big improvement, however this is still explicit/userland asynchronous programming: If anything down the callstack is synchronous, it blocks everything. This requires every components of a program, including every dependency, to be specifically designed for this kind of concurency. Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything a…

> Programming languages have the power to implement concurrency patterns that offer the same kind of performances, without the hassle. Can you give one that reaches this goal? Go is often cited on that regard but it doesn't really fit your description since it trades performance for convinience (interactions with native libraries are really slow because of that) and still doesn't solve all problems since hot loops ca…

> interactions with native libraries are really slow because of that

Can you explain a bit? What is the connection between concurrency implementation (which I am assuming you are talking about multiplexing multiple coroutines over the same OS thread) and say slowness in cgo? Having to save the stack? I don't get it.