socket.recvfrom() & sendto()

Ron Johnson ron.l.johnson at home.com
Thu May 10 07:11:46 CEST 2001


Steve Holden wrote:

> "Ron Johnson" <ron.l.johnson at home.com> wrote ...
>> Steve Holden wrote:
>>
>> > "Ron Johnson" <ron.l.johnson at home.com> wrote in ...
>> > [ ... ]
>> >>
>> >> It seems like the server *and* the client both must use asyncore.
>> >> But does asyncore, underneath it all, sit at select.select() waiting
>> >> on the next readable socket?  So if the client is also using asyncore,
>> >> does it need a thread for network IO and a thread for user
>> >> interaction, and the 2 threads talk to each other?
>> >>
>> > Nope. The advantage of asyncore, and Medusa, is that you don't *need*
>> > separate threads. You create a separate object for each dialog
>> > (connection), which holds the stat information for that connection, and
>> > the whole program just becomes one big select() loop, where each
>> > connection object is told when there is data to be read, when it can
>> > write, and so on.
>> >
>> > So it's a single thread, processing multiple objects asynchronously,
>> > depending on events which are detected by the use of select().
>> >
>> > When you start, it's about as weird as your first GUI-based program --
>> > event-driven programs are held together by string!
>>
>> Interesting.
>>
>> Since the server can send messages to the client at random and
>> irregular interevals, how can the client accept input from the
>> user at the same time that it is "stalled" at a select() ?
>>
> Under Unix I *believe* that select() can treat a tty channel like a
> socket, but under Windows I understand that select() only works on
> sockets. One possibilty (not perhaps the best one) would be to make your
> client module receive input from a separate user interface module over a
> local (loopback)
> socket, which would put user input on a par with network  input at the
> expense of some structural inconvenience.

Well, I've found *1* way that a chat client (curphoo, found on
freshmeat) does it:
it uses a standard select() loop on a socket that times out 
every 1/50th (yes, that's fiftieth, not fifth) of a second, 
*then* it does: 
  inputs, outputs, errors = select.select([sys.stdin],[],[],0.002)
and if the user has not typed anything in, the program returns to
the main select() loop.

I have to believe that that is an expensive way to do things...
Someone else in this thread mentioned something like this, I believe...

-- 
 Ron Johnson, Jr.        Home: ron.l.johnson at home.com
 Jefferson, LA  USA      http://ronandheather.dhs.org
 "Is Python better or worse than Perl?"
  "Perl is worse than Python because people wanted it 
   worse." -Larry Wall, 10/14/1998



More information about the Python-list mailing list