Client with select.select()

Donn Cave donn at u.washington.edu
Tue Jun 13 15:36:43 EDT 2000


Quoth "A[r]TA" <arta at NOSPAMx-stream.nl>:
[quoting myself]
|> I think you also may have the wrong idea about the write-set parameter
|> to select().  The test with select() is ``will I block?''  That is,
|> if read-set returns a file descriptor, you may read from that descriptor
|> without blocking - either there's data, or end of file or whatever may
|> cause a non-blocking state on a blocking descriptor.  The same is true
|> of the write set, mutatis mutandi.  The reader on the other end will
|> probably ignore what you're writing, you just won't block.  Sockets
|> are usually in this state.  I guess it's a good thing to check anyway,
|> but by no means is there any implication that the other end of the socket
|> has requested data.  ("block" means "wait".)
|
| But if you want to write a telnet-client. The server requests for data,
| isn't he?
| Then you can check with the write-set and send some data.
| Or am I missing something?

There is absolutely no way to tell, from your end, whether there is
a read waiting on the other end.  But otherwise, yes, that makes
sense.  Maybe we could write it like this:

    sfd = sock.fileno()
    while 1:
        rfds = [sfd, pty]
        efds = rfds
        wfds = []
        if ptydata:
            wfds.append(sock)
        if socketdata:
            wfds.append(pty)
        rfds, wfds, efds = select.select(rfds, wfds, efds, timeout)
        if sfd in rfds:
            data = sock.recv(16384)
            if data:
                socketdata = socketdata + data
            else:
                   sock.close()
                   raise EOFError
        [and likewise if pty in rfds, read into ptydata]
        if sfd in wfds:
            nbytes = sock.send(ptydata)
            ptydata = ptydata[nbytes:]
        [and likewise if pty in wfds, write from socketdata]

So I check first whether more socket output can be accepted.  I don't
think you will really find this done very often, though, because only
in relatively dire circumstances would select say "no", and even then
it may be OK to simply block.  It's more important to check the amount
actually sent, in any case, because it may be less than the full string
you gave send() and the rest will have to be re-sent.

When I learned to use sockets and pipes, I had already worked with the
somewhat pipe-like VMS MBX device.  It can notify you specifically when
the process on the other end posts a read.  I loved that.  Haven't seen
anything like it since.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list