Comment by edgyswingset | Hacker News Reader

Comment by edgyswingset | Hacker News Reader

Parent Full thread

Think of it this way:

What happens when IIS runs out of threads?

Without async code, it queues of requests and users sit there getting nothing from your server.

With async code, that's not the case! Well, until you reach the limit of what async code does, but that limit is quite high.

Typically a request thread that ends up blocking on I/O in some way (like accessing a database) sits there doing absolutely nothing for a very long time. The time it takes to get data from a database could be spent servicing many, many more requests! Async does just that. And before you ask, it doesn't spawn off any threads ... it leverages the asynchronous nature of the operating system to service I/O requests. It's actually really, really rad.

> Usually seems to be a premature optimization

If you have a user-facing system, it's most definitely not a premature optimization. If you know, for a fact, that you'll never need to worry about responsiveness, they're not worth it.

This is another similar answer: http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-fr....

There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?

> How many do you need?

That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.

> 'to wait for IIS to free up a new thread.'

Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool.

Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes:

    Result IOMethod()
    {
       EventWaitHandle wait = new AutoResetEvent(false);

       // Do your IO - pass in the handle

       wait.WaitOne();
       return result;
    }

Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?

Ok, did a bit of reading for myself. I had obviously only vaguely took in what was said when it was first released as a language feature. So async will run all code on the current thread, until it gets to some IO. At that point it switches to running the code that you'd normally expect to run asynchronously. Once the IO returns it runs the remainder of the async 'closure' (for want of a better word) with the result. A kind of coroutines system, I guess similar to node.js.

Yep! The async model in node.js is very similar.

Here's a fantastic blog post about the details of it all: http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...

There's no way it's creating 32k threads on start up. That's the default max. Threads aren't totally cheap so they alloc a lot less. Asp.net allocates more. Used to be 25 or 50 per CPU.

async doesn't use threads.

Async is a goto state machine. While the IO is set as blocked at the operating system level, it does something else. Then when it's unblocked, it jumps back.

I'm still having a hard time with async. I see lot's of async code using Tasks, pretty much 99% of the time. Wouldn't this make async code using threads anyway?

A task may or may not be run on another thread. It just represents a unit of work with a potential result.

It can be confusing because Task objects original main use was running stuff on background worker threads. That is no longer the case.

Note, you can use async and threads. But a lot of code using async and task are NOT using threads.

Async code, down in the "guts" of the system, will borrow user-level and OS-level threads, so while it's correct that it does use threads, it won't spawn off new ones. Spawning off a new thread ultimately wouldn't accomplish much (after all, why not have IIS just use a new one?).

I like to think of it as utilizing the operating system more efficiently. I/O on a system is asynchronous by default. Async code will essentially delegate work so the OS can do what it does best!

Each of those threads has a stack allocated to it - and from what I understand, the CLR will actually commit a megabyte of RAM for every thread. You really don't want to have all of the threads permitted in the threadpool up and running at once if you can avoid it. Async allows you to handle 32000 simultaneous requests without having to have 32000 threads and 32000 stacks active at once.

Reply on news.ycombinator.com