[mgaunard]

Doing multiple threads per core is not "proper multithreading", since it's a well-known antipattern.

[kristiandupont]

..it's not good because it's bad?

Why is it an anti pattern, this is news to me?

[janhaa]

More threads on a single core equal more context switches, which reduces the effective amount of instructions you can process.

[kristiandupont]

Well sure, but why would that make it "improper multithreading"? Is polymorphism based on vtables not "proper OOP"? We rely on many abstractions that aren't free in terms of CPU cycles because it makes development easier or less error prone.

And setting up, say, one thread per HTTP request will likely be negligible because blocking I/O is where time is spent anyways..

[threeseed]

It's not improper it's just non-optimal.

And we have had non-blocking I/O for quite some time now.

[mgaunard]

Any networking program doing blocking I/O is doing it wrong.

Your I/O should only be done synchronously if it's non-blocking.

Now for disk I/O, it's a more muddy thing, it's actually quite different from networking since it's more transparently managed by the operating system.

[mgaunard]

Kernel threads do not scale, and neither does the scheduler.

Userland threads (or fibers, or stackful coroutines) do scale better though.