[bullen]

Agreed it's simpler, but using NIO with one OS thread per core also has it's benefits.

The context switch (how ever small) will cause latency when this solution is at saturation.

I think they should write four tests: fiber, NIO and each with userspace networking (no kernel copying network memory) and compare them.

Why Oracle is stalling removing the kernel for Java networking is surprising to me, they allready have a VM.

[pron]

https://github.com/ebarlas/project-loom-comparison

[vlovich123]

Shouldn’t you be able to send authorization and authentication requests in parallel in the async and virtual threads cases?

[threeseed]

It is just an example so they could do anything.

But in the real world it is common to need information from the authorization stage to use in the authentication stage. For example you may have a user login with an email address/password which you then pass to an LDAP server in order to get a userId. This userId is then used in a database to determine with objects/groups they have access to.

[vlovich123]

A lower latency design would be for the authorization service to be able to work with either. That way those requests could be done in parallel to reduce latency.

[bullen]

Thx, I'm missing bandwidth and latency in those graphs.

[blibble]

there's still a context switch with NIO, you're just doing it manually

[bullen]

The context switches in NIO is between fewer threads, you just need one per core.

Memory contention is also playing into this.

The benchmark they made is asking the question in a way that it leans into the answer they need, just like 99% of all human activity it's biased.

[blibble]

you're missing the point and taking "context switch" literally

with NIO you are still managing the stack, just yourself instead of letting the operating system do it for you

it is still a "context switch", just done in your code instead of the OS

and that's not free (and likely more expensive than saving and restoring a set of registers)