[mpweiher]

I am fully aware of the approach, especially in languages/systems like Erlang, and the freedom that very cheap threads give you.

My first point was that you actually have much more of this freedom than most people are aware of, even with (comparatively) heavy kernel threads. For example, see the "Replace user threads with ... threads" by Paul Turned (Plumber's Conference): https://www.youtube.com/watch?v=KXuZi9aeGTw

More on that point, I see a lot of user-threading/async craziness on clients such as iOS that would have been easily been handled by less than a dozen kernel threads, most of which would be sleeping most of the time anyhow. That's a number of kernel threads that is easily manageable and not particularly resource intensive.

My second point is that there is one thread that this blocking-happy approach mostly doesn't apply to, and that is the UI thread. You really don't want that UI waiting for (network) I/O and therefore must employ some sort of asynchronous mechanism for data flow and/or notifications.

[pron]

The Paul Turner approach works when you have up to about 10K-20K threads. Beyond that, you lose the ability to model a domain unit-of-concurrency (request/session) as a software unit of concurrency (thread). The kernel-thread approach works as long as you don't hit against the Little's Law wall. Basically, Little's Law tells you exactly when kernel threads become the wrong approach, which depends on the level of concurrency you wish to support and the mean latency of handling each concurrency unit (i.e. request/session).

> My second point is that there is one thread that this blocking-happy approach mostly doesn't apply to, and that is the UI thread.

You're not allowed to block the kernel UI thread, but you can schedule lightweight threads onto the UI thread and block them all you want, so from the programmer's perspective that restriction disappears.

[muraiki]

Sorry, I was just trying to help clarify what was being said -- not trying to argue against your points.