Client with select.select()
Donn Cave
donn at u.washington.edu
Tue Jun 13 15:36:43 EDT 2000
More information about the Python-list mailing list
Tue Jun 13 15:36:43 EDT 2000
- Previous message (by thread): Client with select.select()
- Next message (by thread): Client with select.select()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Client with select.select()
- Next message (by thread): Client with select.select()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list