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

Why you might want async in your project

notgull.net

Post reply on HN
Print view View original

171–180 of 182 posts

Re: Why you might want async in your project

#171

Post by vc8f6vVV »

insanitybit wrote: post #168
Matthias247 wrote: post #164

Earlier quoted context omitted.

You can cancel socket operations using signals. You can eg have one or more background threads running timers which will interrupt the blocking IO if it doesn’t return in a timely manner. A lot of very important frameworks and services that are used in billions of transactions per day use this model.

Of course you can. It does mean that you need cooperation between the child and parent thread (to set up the signal handler so that resources are cleaned up) though. That's easy in a framework, kind of a pain in the ass if you're just trying to get some opaque client you were passed to do something in And that's just for IO. I mentioned elsewhere that you may want to cancel pure compute work. You can see my point, I…

Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of a framework?

Re: Why you might want async in your project

#172

Post by Matthias247 »

vc8f6vVV wrote: post #171
insanitybit wrote: post #168

Earlier quoted context omitted.

Of course you can. It does mean that you need cooperation between the child and parent thread (to set up the signal handler so that resources are cleaned up) though. That's easy in a framework, kind of a pain in the ass if you're just trying to get some opaque client you were passed to do something in And that's just for IO. I mentioned elsewhere that you may want to cancel pure compute work. You can see my point, I…

Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of…

The last comment is actually pretty interesting and spot on. In the Java/JDK world - which you can assume as a „framework“ - you can cancel blocking IO via the Thread.interrupt() mechanism. And that works because it’s deeply integrated into the framework, similar like async Rust runtimes provide support for cancellation.

Re: Why you might want async in your project

#173

Post by insanitybit »

vc8f6vVV wrote: post #171
insanitybit wrote: post #168

Earlier quoted context omitted.

Of course you can. It does mean that you need cooperation between the child and parent thread (to set up the signal handler so that resources are cleaned up) though. That's easy in a framework, kind of a pain in the ass if you're just trying to get some opaque client you were passed to do something in And that's just for IO. I mentioned elsewhere that you may want to cancel pure compute work. You can see my point, I…

Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of…

Without any yielding? Seems hard. You could park the thread idk.

> what's the difference between "framework" and async/await runtime,

Sure, in that in both cases you have the threads managed for you. But there's a difference between spawning a raw pthread, which will have no signal handlers/ cleanup hooks, and one managed by a framework where it can add all of those things and more.

Re: Why you might want async in your project

#174

Post by conradludgate »

vc8f6vVV wrote: post #170
conradludgate wrote: post #165

Earlier quoted context omitted.

You either wait on the channel or wait on a read. How do you manage both?

You wait on a shared channel so both read and sleep threads queue a message when ready (whichever comes first). Not sure about channels, but in other languages it would be a concurrent queue.

This won't cancel the read, it'll just ignore the result

Re: Why you might want async in your project

#175

Post by vc8f6vVV »

conradludgate wrote: post #174
vc8f6vVV wrote: post #170

Earlier quoted context omitted.

You wait on a shared channel so both read and sleep threads queue a message when ready (whichever comes first). Not sure about channels, but in other languages it would be a concurrent queue.

This won't cancel the read, it'll just ignore the result

Most languages I know allow killing a thread, or at least unblock a system call.

Re: Why you might want async in your project

#176

Post by [deleted] »

Matthias247 wrote: post #172
vc8f6vVV wrote: post #171

Earlier quoted context omitted.

Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of…

The last comment is actually pretty interesting and spot on. In the Java/JDK world - which you can assume as a „framework“ - you can cancel blocking IO via the Thread.interrupt() mechanism. And that works because it’s deeply integrated into the framework, similar like async Rust runtimes provide support for cancellation.

[deleted]

Re: Why you might want async in your project

#177

Post by vc8f6vVV »

insanitybit wrote: post #173
vc8f6vVV wrote: post #171

Earlier quoted context omitted.

Can you cancel a tight computing loop (i.e. without system calls and without yielding of any sort) with async? I wonder how? Also if you can inject a cleanup code in your async task what prevents you from doing it with threads? Such things existed long before async/await and system calls didn't change for async/await. Also, what's the difference between "framework" and async/await runtime, isn't the latter a kind of…

Without any yielding? Seems hard. You could park the thread idk. > what's the difference between "framework" and async/await runtime, Sure, in that in both cases you have the threads managed for you. But there's a difference between spawning a raw pthread, which will have no signal handlers/ cleanup hooks, and one managed by a framework where it can add all of those things and more.

Interesting, in the Java world Thread.stop is deprecated too: https://docs.oracle.com/javase/7/docs/technotes/guides/concu... Which means there is no good way to actually stop a thread involuntary. Of course in most simple apps it's not a big deal, but I would not do it in long-running apps.

OTOH in Rust async model is based on polling. Which means that poll may never block, but instead has to set a wake callback if no data is available. So there is no way to interrupt a rogue task and all async functions should rely on callbacks to wake them (welcome to Windows 3.1, only inside out!). Thread model is much more lax in this sense, e.g. even though my web server (akka-http) is based on futures, nothing prevents me from blocking inside my future, in most cases I can get away with it. As I understand it's not possible in Rust async model, I can only use non-blocking async functions inside async function. So in reality you don't interrupt or clean up anything in Rust when a timeout happens, you simply abandon execution (i.e. stop polling). I wonder what happens with resources if there were allocated.

Re: Why you might want async in your project

#178

Post by insanitybit »

vc8f6vVV wrote: post #177
insanitybit wrote: post #173

Earlier quoted context omitted.

Without any yielding? Seems hard. You could park the thread idk. > what's the difference between "framework" and async/await runtime, Sure, in that in both cases you have the threads managed for you. But there's a difference between spawning a raw pthread, which will have no signal handlers/ cleanup hooks, and one managed by a framework where it can add all of those things and more.

Interesting, in the Java world Thread.stop is deprecated too: https://docs.oracle.com/javase/7/docs/technotes/guides/concu... Which means there is no good way to actually stop a thread involuntary. Of course in most simple apps it's not a big deal, but I would not do it in long-running apps. OTOH in Rust async model is based on polling. Which means that poll may never block, but instead has to set a wake callback if…

> As I understand it's not possible in Rust async model,

You can block, you're just going to block all other futures that are executed on that same underlying thread. But all sorts of things block, for loops block.

This is the same as Java, I believe. Akka also has special actors called IO Workers that are designed for blocking work - Rust has the same thing with `spawn_blocking`, which will place the work onto a dedicated threadpool.

> So in reality you don't interrupt or clean up anything in Rust when a timeout happens

You don't interrupt, you are yielded to. It's cooperative.

> I wonder what happens with resources if there were allocated.

When a Future is dropped its state is dropped as well, so they are all freed.

Re: Why you might want async in your project

#179

Post by insanitybit »

klabb3 wrote: post #158
insanitybit wrote: post #154

Earlier quoted context omitted.

Relying on the socket APIs is a bit painful. For one thing, what if that socket is shared across tasks? What if I want to do per-request timeouts? What if I don't want to expose the socket APIs to callers? What if my work isn't related to socket timeouts? For example, downloading a multi-part file? I may want a very long socket timeout but still have a distinct timeout for the individual chunked operations. It might…

> For one thing, what if that socket is shared across tasks? Yeah that’s an issue. In Go they sync it (thread safe), which in Rust would translate to interior mutability. > What if I want to do per-request timeouts? Ah you’re right in http2 there can be multiple concurrent reqs per conn. Go still allows request based timeouts, but I wonder if that’s possible with the limited primitives in std. It’s also true that thi…

> Btw which libs are you referring to for network requests?

Consider this: https://docs.rs/rusoto_s3/latest/rusoto_s3/trait.S3.html

You're given a trait and, understandably, this trait does not expose any sockets to you (it may not even be backed by sockets).

Re: Why you might want async in your project

#180

Post by vc8f6vVV »

insanitybit wrote: post #178
vc8f6vVV wrote: post #177

Earlier quoted context omitted.

Interesting, in the Java world Thread.stop is deprecated too: https://docs.oracle.com/javase/7/docs/technotes/guides/concu... Which means there is no good way to actually stop a thread involuntary. Of course in most simple apps it's not a big deal, but I would not do it in long-running apps. OTOH in Rust async model is based on polling. Which means that poll may never block, but instead has to set a wake callback if…

> As I understand it's not possible in Rust async model, You can block, you're just going to block all other futures that are executed on that same underlying thread. But all sorts of things block, for loops block. This is the same as Java, I believe. Akka also has special actors called IO Workers that are designed for blocking work - Rust has the same thing with `spawn_blocking`, which will place the work onto a ded…

If you block your timer goes out the window, right? Because the poll will never get there until the blocking call is done. So yeah, you can block, but it will disrupt the whole chain, including tasks above yours up to await. Similar to Erlang VM where the language itself yields (e.g. there are no loops and every recursive call is effectively a yield), but if you add a C module and are careless enough to block, the whole EVM blocks. So no, if you want to use async you shouldn't block. For loops? Nope, not if they take long time for the same reason, you may want to break them down to smaller chunks ("long" depends on other tasks and expected latency).

Having said that, Erlang exists and doing well, so async is as good as any model designed for special cases. But this discussion basically answers the question

> Why don’t people like async?

Because not everybody (which means a majority of developers) needs this complexity. And the upward poisoning means that I can't block in my function if my web server is based on async, which affects everybody who is using it.

Post reply on HN