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

Re: [pygame] Threads




On Apr 16, 2005, at 3:55 PM, Pete Shinners wrote:

For the most part, the only parts of your program that should deal with
pygame are the main thread. There are a few things that are thread safe
in pygame.

Any thread can post new events the event queue. Only the primary thread
can read or pump the queue, but anyone can put events into it. The sound
system is also pretty thread safe, so the audio can be played from any
thread.


The display and graphics are pretty much exclusively allowed to
communicate with the primary thread. If you are very careful you can do
some software Surface operations on background threads, but I'd
recommend not doing it because not every call is safe, and different
platforms will have their own ideas of what you can do.

Using Python, threads themselves are of limited use. The only real area
they will show a benefit is when waiting on slow IO operations (network
and file).

Usually I'd recommend against using threads, and trying to break
operations down into small slices. With networking this can get a bit
tricky, although many of the Python socket calls do allow timeouts.
Threads can be a big win for some sitations. All of the audio mixing in
pygame uses threads.

I wrote a Twisted reactor this weekend that uses threads (*a* thread), sparingly, to integrate with foreign event loops. I have also provided a pygame example. It's probably worth checking out.


http://bob.pythonmac.org/archives/2005/04/17/twisted-and-foreign-event- loops/

-bob