how do I listen on a socket without sucking up all the CPU time?
gangli at msn.com
gangli at msn.com
Tue Oct 3 19:32:31 CEST 2000
have you look into timeoutsocket.py.
In article <8rd007$9mt0$1 at nntp6.u.washington.edu>,
Donn Cave <donn at u.washington.edu> wrote:
> Quoth "Joshua Muskovitz" <josh at open.com>:
> |> Why is the socket set to non-blocking? Why not set it to
> |> blocking so that the thread blocks until there's data to read?
> | This is one of those "um" questions. The answer is "um, well, the
> | code I was given to start with set it to non-blocking." <insert
> | grin here>
> | The only reason I can thing of is that a separate thread needs to
be able to
> | use the same socket to send requests (send and recv operate on the
> | socket in different threads), but this may not be a valid reason
> Now that you have select() working, there's no reason to make the
> non-blocking. I have never understood the attraction of non-blocking
> I/O. In a well designed program it never seems to be needed, and it
> appears in places where it is not apparently used.
> I have had some trouble with concurrent I/O on a single socket in
> threads. I think concurrent access to any device is asking for
> | select.select worked great, but now I've got other problems, namely
> | figureing out why I'm no longer catching the KeyboardInterrupt
> | used to be able to catch.
> Note that signals can be delivered only to the main thread, and as
> already mentioned in another followup, the handler doesn't execute
> immediately at the C level, but rather immediately at the Python
> which could really be a long time later.
> Donn Cave, donn at u.washington.edu
Sent via Deja.com http://www.deja.com/
Before you buy.
More information about the Python-list