https://kotlinlang.org logo
n

Niklas Gürtler

02/03/2021, 2:03 PM
Depends on how you use them - if you
read
one socket and it takes a long time for a message to arrive, the thread is blocked and can't
read
from another socket, even if data is already available there, so the other socket's can experience poor latency. If you do that on multiple threads, or never need to process I/O simultaneously on multiple sockets anyways, this is moot.
🧵 3
k

Karlo Lozovina

02/03/2021, 2:06 PM
I'm gonna use thread-per-connection model with either Socket or SocketChannel, so I don't mind blocking the thread. I was just not sure if maybe SocketChannels were still preferable (maybe newer code, better usage of OS primitives, etc etc)
n

Niklas Gürtler

02/03/2021, 2:07 PM
Right, not sure. The thread-per-connection model always has some overhead but that's not neccessarily bad
k

Karlo Lozovina

02/03/2021, 2:08 PM
Yeah, googling around doesn't show that either is vastly better when having low concurrency... so I'll go with the simpler option
n

Niklas Gürtler

02/03/2021, 2:09 PM
The thread synchronization can become so much hassle that async I/O can actually become easier
5 Views