socket.recvfrom() & sendto()

Grant Edwards grante at
Thu May 10 16:52:12 CEST 2001

In article <9ddbbj$pkk$1 at>, Donn Cave wrote:

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

OK, so it _does_ "stall" in the select() when there's nothing
to do.  That is a good thing.

>I have no idea why asyncore sets its sockets to nonblocking.

Don't know about that, I was just surprised at the claim that
asyncore didn't block on select().

Grant Edwards                   grante             Yow!  I'LL get it!! It's
                                  at               probably a FEW of my
                                 ITALIAN GIRL-FRIENDS!!

More information about the Python-list mailing list