Does blocking mode put that particular task in a "Process Wait" state, as i think non-blocking sockets needs a "busy-wait" or "spin-lock" implementation, explicitly from the user. Or blocking mode sockets are nothing but implicit-implementations of busy-wait by the kernel.
In locking mechanisms like semaphores/mutexes/monitors a lock is usually achieved by pushing the task in Blocked State. I think if such things are possible with locking, then socket locking might also be achieved by same way.
I dont know for sure, I think polling is not a efficient way, esp for the kernel, as the kernel always has his hands full with so many tasks.
thx.
No, blocking sockets are implemented in the kernel. The process is into a non-executing state, and does not consume any CPU time.
The kernel is free to run other tasks until some outside activity would cause it to wake the task up. For instance, a hardware interrupt for the network card letting it know there is data to be read. The kernel reads it and pushes it through the network stack, eventually waking up the application to process the data.
Timers would work the same way, but with the timer interrupt.
The kernel might actually be polling hardware under the hood, but it doesn't have to be... that's all a matter of how the hardware is designed.
Please see my answer to this question: C++ - how does Sleep() and cin work?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With