[umanwizard]

Why would cores be waiting? A thread blocked on synchronous I/O will in general not be scheduled on a core. This is true on all OSs that I’m aware of.

Not sure if Apache had some spin-wait loops or something, but if so then that was a bug in Apache, not a fundamental characteristic of doing synchronous I/O in threads.

[GrayShade]

You're still paying some costs: there might be scalability issues in the scheduler data structures (how long does it take to schedule one thread out of a million blocked ones?), you need memory to store their stacks (hope you're on 64-bit), when they become runnable, you have a lot of context switches (which cost even more now after the Spectre fixes). Probably others that don't come to mind right now.

As for Apache, it spins a number of processes up to a point. When there aren't any free ones, the clients don't get any data.

[umanwizard]

Yes, I pointed all of this out in another reply:

> For one thing, threads take up memory and address space, and create work for the scheduler.

It is the right answer. "Cores are waiting" is not the right answer.

[twic]

Async is about servicing thousands, or tens of thousands, of clients at once. Since everyone is convinced that their program will have tens of thousands of clients, they clamour for async.

[sitkack]

This is about servicing tens of thousands of connections. Threads are ok in the low thousands, but now servers are in the realm of handling millions of current connections.

https://stackoverflow.com/questions/22090229/how-did-whatsap...

[mlindner]

Creating a thread for every connection consumes massive amount of memory and is a known anti-pattern.

[umanwizard]

How does this contradict my comment?

[elihu]

Part of the problem is that context switches are really slow, so for software that needs maximum performance people will go to great lengths to avoid them.