0

I wonder what happens in the background when calling a blocking function. Let's take recv() for example.

When that function gets called, is there another process outside my program that uses some mutex-like function to block my thread / process? (And there, the other process sits in an endless loop waiting for an update)

Can someone please give me better insight into how it works. It feels like somewhere there must be a loop that spins endlessly

Arre
  • 125
  • 1
  • 7
  • It's done by interacting with the OS's thread-scheduler to put your thread to sleep until data is ready to be read, at which point your thread gets woken up again. (the "process outside your program" is the OS's kernel and networking stack) Have a look at this question and its answer: https://stackoverflow.com/questions/28400063/context-switches-on-sleeping-waiting-threads/28402906#28402906 – Jeremy Friesner May 22 '20 at 16:08
  • @JeremyFriesner Hello and thanks for your reply. Based on your answer, that should mean that the os scheduler has a thread that is stuck in a loop (checks for updates each repetition) and does not return until it has received data? Am I right? – Arre May 23 '20 at 15:08
  • No, there is no thread stuck in a polling loop; that would be inefficient (no better than having your own thread in a polling loop). The only thread is your program's thread, which gets placed into the scheduler's waiting-threads list (and thus never gets to run at all) until some network data is available for `recv()` to return. At that point, the networking interrupt will tell the scheduler to take your program's thread out of the waiting-threads list and put it back into the ready-to-run threads list, and that will cause the scheduler to wake up your thread and let it continue running. – Jeremy Friesner May 23 '20 at 20:16

0 Answers0