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

What async promised and what it delivered

causality.blog

Post reply on HN
Print view View original

201–210 of 317 posts

Re: What async promised and what it delivered

#201

Post by RustyRussell »

mbid wrote: post #39

How many systems are there that can't just spawn a thread for each task they have to work on concurrently? This has to be a system that is A) CPU or memory bound (since async doesn't make disk or network IO faster) and B) must work on ~tens of thousands of tasks concurrently, i.e. can't just queue up tasks and work on only a small number concurrently. The only meaningful example I can come up with are load balancers,…

I agree: fork is fast, cheap and easy. If you're spawning something for significant work it tends to be in the noise.

Linux kernel uses 8k stacks (TBH, it's been a while), but there's also some copy-on-write overhead. Still, this is not the C10k problem...

Re: What async promised and what it delivered

#202

Post by comex »

iknowstuff wrote: post #179
ysleepy wrote: post #109

Earlier quoted context omitted.

Java has gone full circle. Java had green threads in 1997, removed them in 2000 and brought them back properly now as virtual threads. I'm kinda glad they've sat out the async mania, with virtual threads/goroutines, the async stuff just feels like lipstick on a pig. Debugging, stacktrackes etc. are just jumbled.

In Rust debugging and stacktraces are perfectly fine because async/futures compile to a perfect state machine.

They are not perfectly fine. If a task panics then you will get the right stack trace, but there is no way to get a stack trace for a task that’s currently waiting. (At least not without intrusive hacks.)

Re: What async promised and what it delivered

#203

Post by cma256 »

kibwen wrote: post #87

> Language designers who studied the async/await experience in other ecosystems concluded that the costs of function coloring outweigh the benefits and chose different paths. Not really. The author provides Go as evidence, but Go's CSP-based approach far predates the popularity of async/await. Meanwhile, Zig's approach still has function coloring, it's just that one color is "I/O function" and the other is "non-I/O f…

That is an unfair characterization of Zig. The OP correctly points out:

> Function signatures don’t change based on how they’re scheduled, and async/await become library functions rather than language keywords.

The functions have the same calling conventions regardless of IO implementation. Functions return data and not promises, callbacks, or futures. Dependency injection is not function coloring.

Re: What async promised and what it delivered

#204

Post by FpUser »

in real life when request handler call async/colored/whatnot it lets the call proceed and immediately ready to process next request. The backend then would have no problems to create ever growing number of asyncs currently in flight. In real life those asyncs would most likely end up calling database. The end result is that backend would simply overwhelm the database and other resources that have to maintain states of those countless asyncs in flight.

This whole thing is basically snake oil. The best thing backend can do instead is have dedicated thread pool where each real thread has its own queue of limited size. Each element in queue would contain input and output state of request and code to deal with those. Once queue grows over certain size the backend should simply immediately return error code (too busy). Much more sound strategy in my opinion.

There are more complex cases of course (like computationally expensive requests with no io that take long time). Handling those would require some extra logic. Async stuff however will not help here either

Re: What async promised and what it delivered

#205

Post by satvikpendem »

kibwen wrote: post #87

> Language designers who studied the async/await experience in other ecosystems concluded that the costs of function coloring outweigh the benefits and chose different paths. Not really. The author provides Go as evidence, but Go's CSP-based approach far predates the popularity of async/await. Meanwhile, Zig's approach still has function coloring, it's just that one color is "I/O function" and the other is "non-I/O f…

Or use OCaml 5 which has a full algebraic effects system that solves the function coloring problem while still being highly performant.

Re: What async promised and what it delivered

#207

Post by YZF »

otabdeveloper4 wrote: post #190
YZF wrote: post #100

Earlier quoted context omitted.

Pretty much anything that needs performance and has a lot of relatively light operations is not a candidate for spawning a thread. Context switching and the cost of threads is going to kill performance. A server spawning a thread per request for relatively lightweight request is going to be extremely slow. But sure, if every REST call results in a 10s database query then that's not your bottleneck. A query to a datab…

> Context switching No such thing. In a preemptive multitasking OS (that's basically all of them today) you will get context switching regardless of what you do. Most modern OS's don't even give you the tools to mess with the scheduler at all; the scheduler knows best.

That's not accurate. Preemptive multitasking just means your thread will get preempted. Blocking still incurs additional context switching. The core your thread is running on isn't just going to sit idle while your thread blocks.

Re: What async promised and what it delivered

#208

Post by dwattttt »

cma256 wrote: post #203
kibwen wrote: post #87

> Language designers who studied the async/await experience in other ecosystems concluded that the costs of function coloring outweigh the benefits and chose different paths. Not really. The author provides Go as evidence, but Go's CSP-based approach far predates the popularity of async/await. Meanwhile, Zig's approach still has function coloring, it's just that one color is "I/O function" and the other is "non-I/O f…

That is an unfair characterization of Zig. The OP correctly points out: > Function signatures don’t change based on how they’re scheduled, and async/await become library functions rather than language keywords. The functions have the same calling conventions regardless of IO implementation. Functions return data and not promises, callbacks, or futures. Dependency injection is not function coloring.

These things _are_ function colouring, but they show function colouring isn't scary or hard.

The original function colouring essay was much more about JavaScript's implementation than a general statement.

If JavaScript had exposed a way for a synchronous function to call back into the runtime to wait for an async function to complete, it would still be just as coloured, but no one would be complaining about colour (deadlocks yes, but that's another kettle of fish).

Re: What async promised and what it delivered

#209

Post by monocasa »

asdfasgasdgasdg wrote: post #182
monocasa wrote: post #161

Earlier quoted context omitted.

Except if those threads are actually faulting in all of that memory and making it resident, they'd be doing the same thing, just on the heap, for a classic async coroutine style application.

If you have hugepages enabled, all of those threads are probably faulting in a fair amount of memory.

Only if you've actually faulted in 2MB contiguously already.

Re: What async promised and what it delivered

#210

Post by smallstepforman »

jemfinch wrote: post #198

> OS threads are expensive: an operating system thread typically reserves a megabyte of stack space and takes roughly a millisecond to create. It's typically less than a hundred kilobytes and (on the systems I've benchmarked using std::thread) it takes 60usec (wall time in userspace) to create and destroy a thread. Threads have gotten so fast that paying the async function coloring price makes very little sense for m…

Its the stack space allocated to each thread that prevents you from spawning more than a thousand threads. Strategies like a thread per network connection do not scale.
Post reply on HN