socket.recvfrom() & sendto()
donn at oz.net
Thu May 10 02:09:55 EDT 2001
Quoth grante at visi.com (Grant Edwards):
| In article <LRcK6.9510$sk3.2586223 at newsb.telia.net>, Fredrik Lundh wrote:
|> Grant Edwards wrote:
| (quoting Jonathan Feinberg)
|>|> It is never "stalled" at a select(); asyncore uses non-blocking
|>|> sockets. select() returns immediately with lists of those sockets
|>|> which are ready to write and those sockets which are ready to read.
|>| So it's in a busy-wait loop burning CPU time when there's
|>| nothing to do? That's just plain evil...
|> what makes you think any operating system would implement
|> select in that way?
| It was claimed that the program was never "stalled" at a
| If the program is never blocking in the select() call because
| the select timeout was set to 0, then it is in a busy-wait loop
| calling select() (which returns 0 immediately) as fast as it
| can. Or did I misunderstand?
I think these days the busy/idle loop is pretty rare, and when
you see that select would return immediately, I guess you would
reasonably infer the presence of some other dispatching model.
But from what I can tell, whether asyncore sockets are blocking
or non-blocking makes no difference. It does use select to
dispatch, and select does block. I have no idea why asyncore
sets its sockets to nonblocking.
Donn Cave, donn at oz.net
More information about the Python-list