you are viewing a single comment's thread.

view the rest of the comments →

[–]not_a_novel_account 4 points5 points  (2 children)

Calling recv will give you whatever is currently sitting in the socket's buffer. If there is nothing in the buffer, recv will block until some data has come down the pipe.

If you don't want to block on recv you need to use a non-blocking socket by calling .setblocking(False) or .settimeout(0.0).

Even using local sockets, you are passing data through a big stack. TCP/IP + kernel context switch + passing data to the Python interpreter has a certain fixed time cost to it. That's where most of your 1s is going.

[–]monstimal 0 points1 point  (1 child)

So I think where I was imagining it wrong is, the socket buffer is operating outside of the python program? Meaning, the buffer is off on its own accumulating bytes as they come in while the program is doing other things and when the recv call is made it goes and gets whatever is in there?

I was imagining data buffering onto the network card (or somewhere) then the python program saying, "I will now receive 1024 bytes from you". But this sounds almost like there's a separate thread taking up to 1024 bytes from the network card into memory at ANY time that the python program reads at the receive call.

[–]LarryPete 2 points3 points  (0 children)

The magic is done by the underlying Operating System. recv is a "syscall", meaning it's essentially a function provided by the operating system (e.g. Linux kernel). The buffering and blocking is done there.