Depends on how you use them - if you `read` one s...
# announcements
n
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
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
Right, not sure. The thread-per-connection model always has some overhead but that's not neccessarily bad
k
Yeah, googling around doesn't show that either is vastly better when having low concurrency... so I'll go with the simpler option
n
The thread synchronization can become so much hassle that async I/O can actually become easier