threads

os => listening for multiple sockets on the same/one thread rather one thread per socket jre => listening for multiple sockets on the same/one thread rather than one thread per socket

so what happens is, even if os is doing this optimization that it’s listening for multiple sockets on the same thread but if jre is using multiple threads, where each thread maps to same , what is happening is thread context switching. for each thread when we receive something at that socket. it’s there so we don’t go crazy with threads. since more threads more context switching. the basis of thread pool is. we can use a single thread for more than just doing one task. let’s create some threads and use a schedular which will schedule the tasks on these threads. so, we don’t go crazy creating thread. esp, for short lived operations. cause thread creation is also a heavy. now consider the case of ThreadPool. in that let’s say one runnable is scheduled on some thread. but that can block right. so we got limited by the no of thread in that pool. all the threads will be blocked and still, thread context. thread context is like when we block on io, the native thread is put to sleep and woke up via signal. and at that time context switching happens. now lets say we have 1000s io. create 1000 thread. what else way? you can’t go with 4 threads right. at a time only 4 thread can wait on io. throughput goes down, latency goes up. now take the case of single thread listening/blocked on io for multiple sockets in jre. this is non blocking. whenever a request comes for any on these sockets the thread wakes up puts the task on thread-pool and again goes into blocking/sleeping. how is thread-pool is helping => no thread creation, less context switching. since only say 10 thread. and same thread can execute multiple tasks.

also, coroutines are same as Executor.newWorkSteelingPool() just structured concurrency. ForkJoinTask gives same kind of thing but coroutines are much better like the thing with kotlin, syntactic sugaring.

also, just thinking it also depends right. maybe having multiple threads will much beneficial if i want to parallel download files. rather than this. tbh, idk… but i think… not beneficial as such, but that posses more implementation issues. makes it harder. than just having multiple threads. like with tasks/runnables are not linked right. and maybe, like maybe this is where kotlin coroutines shines. you can access the old data. is it though? still there might be some implementation challenges…

actually what if i just spike all this out? should i? idk… let’s see… will be a good challenge, will definitely learn stuff.