Hacker News Reader

Comment by kristianp | Hacker News Reader

I think the idea behind c# async await was that you could use multple threads without having to worry about the details. It seemed redundant to me to have awaits in a web server. That runs multiple threads already, why does my code have to be async now? I hated it too.

View on HN

Because of I/O.

Without any kind of async (this includes green threads) you run out of (OS) threads very fast.

This is not a black/white decision whether Async makes sense for every API all the time or never.

It's a solution to a specific problem that occurred (and still occurs) a lot.

The article was just about the syntax though, because they are still using asynchronous programming via coroutines (or goroutines ;-))

It's not about syntax. There is a huge difference in implementation and semantics between stackful coroutines (which go uses) and stackless coroutines (which most languages with async/await use).

For all practical purposes goroutines behave as separate threads with blocking calls. The fact that they are multiplexed on a few system threads is an implementation detail.

Otherwise you could say that using system threads directly is also asynchrnous programming. After all, your thread gets suspended on system calls (including synchronization primitives) and is resumed upon their completion.

I don't think there is a huge difference: you can implement stackful coroutines via heap allocated frames a-la scheme that look a lot like separately suspended stackless coroutines. Conversely you can combine chains of stackless coroutines waiting on each other in a single object (I think rust is for example capable of this in principle).

Semantically the biggest difference is that stackless coroutines typically require yield points to be marked syntactically in code.

> you run out of (OS) threads very fast.

What does run out mean?

Each thread is tied to an OS thread, which is tied to a CPU core/hyper-thread. You get like ~6000 threads on a modern OS and CPU.

Your program needs one million threads that sleep for 2 seconds, read some data and then finish. Guess what? Your execution is going to take hours, or get some kind of exception that you run out of threads because after the first ~6000 threads are taken, your OS can no longer give threads to anything else.

With Green threads, the threads are fake aka virtual and controlled by the language's runtime, be it JVM, CLR, Go's runtime etc. Runtime is usually smart enough to recognize sleeps and, while waiting for something, schedule another thread in its space.[1] So now all one million threads start near instantly and work almost all in parallel.

[1]https://www.youtube.com/watch?v=bOnIYy3Y5OA

Desktop OS may struggle at thousands of thread. Linux can handle many more just fine.

> Your program needs one million threads that sleep for 2 seconds, read some data and then finish.

I have yet to see this problem, but yeah I agree that millions is about when there will be problems.

Although it seems async/await is based on multiple threads, this is not the case. To learn about this, read this blog post: https://blog.stephencleary.com/2013/11/there-is-no-thread.ht... Please let me know what you think.

Reply on news.ycombinator.com