select.select question

[Heiko Wundram]

Hey to all!

I'm a little dumbfounded by the following problem I seem to be
encountering when using the select.select module. The code basically
looks like the following:

class RequestHandler(SocketServer.BaseRequestHandler):
    def handle():

	# Read in command and data length in blocking mode.
	command, length = ...

	# Set nonblocking and initialize data.
        self.request.setblocking(0)
	data = ""

	# Read until data has been completely read
	while len(data) < length:
	    (rlist,wlist,xlist) = select.select([self.rfile],[],[],5.0)

	    # Connection dumped.
	    if not rlist:
		return

	    # Read piece of data.
	    data += self.rfile.read(length-len(data))

	# Do something with data and command.
	...

The funny thing is that the command and the length (which are read in
standard/blocking mode) are read correctly, but the select call always
returns an empty list for the read available list. It is just the same
if I specify the socket directly (self.connection/self.request).

Doing a print self.rfile.read(1) right after the select doesn't block
and returns the next character correctly (which is there, I am sure of
that!), even though the rlist is empty! And setting the timeout to zero
just blocks the process as a whole, although self.rfile _is_ readable...

Has anybody experienced this problem before? What am I doing wrong? I
remember writing similar code in Perl, also using select, and that
worked just fine... That was pretty much the last time I was using
select, as I've found pythons threading SocketServer much more
convenient than writing a select based server... :)

Thanks for any answers!

btw. I want to use the select call to dump connections which don't react
anymore, or are so slow that it is unnecessary to keep a connection open
to the server. The handler has its own thread (it is called from a
SocketServer/ThreadingMixIn derived class). Dunno if this is a source of
problem, using a select in a subthread. Doesn't state that in the
documentation anywhere, though.

Yours,

	Heiko Wundram