[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SOC Proposal: Networking for Pygame


On May 8, 2006, at 8:50 AM, Peter Shinners wrote:

On Mon, 2006-05-08 at 01:59 -0700, Bob Ippolito wrote: 
select.select blocks exactly no longer than you ask it to.
pygame.event.get blocks until it gets an event. For an application
that mostly just waits for events (mouse, keyboard) via
pygame.event.get is not going to interoperate well with network
events if it only polls the network after some user input.

The whole point of select is that a single threaded application can do
nonblocking IO. There aren't any real games that use pygame.event.wait()
because it means you can't have any animation. So there shouldn't be any
sleeping or blocking the networking or input needs to interrupt each
other.

That's not true, it's actually a common pattern to multiplex all socket event listening in an auxiliary thread. Mac OS X's networking is implemented in this way, for example, because the main loop is blocking on a "pygame.event.wait" equivalent (mach ports). When a socket event happens, it sends a mach message to the main runloop which wakes up and handles the event(s).

I would still prefer to see a single threaded solution. But as long at
it is transparent (like SDL_mixer) I don't have a problem with threads.

A single threaded solution is only good if you're polling SDL frequently. pygame.event.wait() is counter to single-threaded networking.

-bob