socket.recvfrom() & sendto()

[Donn Cave]

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
| select().  
|
| 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