Re: [pygame] Threads

[Rene Dudfield <renesd@xxxxxxxxx>]

Hey Bob,

nice work!  That does indeed look very unobtrusive compared to any
other twisted integration I've seen.


One question though... how often does the iterateTwisted function need
to be called for good network throughput/latency?

As games with a low fps may only call it only eg 25-60 times a second.
 Any other ways of speeding up the number of times it is called?  I
think the sdl event queue is limited to

One way would be to run anoher thread which peeks at the sdl event
queue for twisted events, and then runs the iterateTwisted function. 
However it looks like sdl events are not thread safe according to
this.    http://www.gameprogrammer.com/fastevents/fastevents1.html 
Not sure if this is true for pygame or not...  I'll check.


Maybe twisted might like to be called more than once per event loop
iteration(or 30 times?), and you may only need to call it once?  Like
if lots of network packets arrived.  Apparently only 100 events per
second can go into SDL.  Can twisted make sure somehow that it limits
the amounts of requests it puts in?  Otherwise other sdl events may be
lost.

The postTwistedEvent function could be modified to peek at the SDL
event queue.  Is postTwistedEvent called from another thread?  If so
then we need to put some sort of protection around the event
functions.

def postTwistedEvent(func):
    # if there is allready a twisted event for iterating twisted on
the queue do not post another one.
    if not pygame.event.peek([TWISTEDEVENT]):
        pygame.event.post(pygame.event.Event(TWISTEDEVENT, iterateTwisted=func))



This loop could be used instead to only iterate twisted once per game loop.

    while not shouldQuit:

        events = pygame.event.get():

        # only iterate for one of the twisted events this loop.
        twisted_events = filter(lambda x:x.type == TWISTEDEVENT, events)
        if twisted_events:
            twisted_events[0].iterateTwisted()

        for event in events:
            if event.type == QUIT:
                reactor.stop()
            elif event.type == KEYDOWN and event.key == K_ESCAPE:
                reactor.stop()










On 4/18/05, Bob Ippolito <bob@xxxxxxxxxx> wrote:
> 
> 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
> 
>