socket.recvfrom() & sendto()

[Ron Johnson]

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() ?  

The server side I think I understand, at least from the perspective
of *my* needs: the server sits at a select() until it detects (an) 
incoming message(s) from client(s); it then processes the message,
sends messages back to the sending client(s) and also possibly other 
clients, then goes back to the select().

Many thanks,
Ron
-- 
 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