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

Re: [pygame] Threads




On Apr 17, 2005, at 9:07 PM, Rene Dudfield wrote:

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?

You call it exactly as many times as it calls you. Although it might call your waker with an identical callable object every time, it's none of your business. You shouldn't try and call it more than once, or ELSE.


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

You call it as often as you process events... If you don't process events very often, you're not going to be very responsive to anything (keyboard, mouse, or network).


Note that the example I posted is just a minimal skeleton example, not The Ultimate Way To Interleave Pygame. The example will never have the 100-event problem because it just sits there and spins, because it never sleeps or calls pygame.event.wait :)

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.

No. That would be bad. Then you'd lose all the benefits of being able to safely call Twisted stuff from your main thread.


I think you misunderstand the referenced URL. SDL events *are* thread safe, they're just not high performance in the face of threads and events will be dropped if the queue is full.

pygame's events are thread safe, but they inherit all the ugly from SDL and SDL_WaitEvent (including dropping upon full queue). Obviously the example I posted, which I wrote in 5 minutes, isn't full-proof.

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.

It doesn't post another event until you call the function it passed over to you. So, Twisted is only responsible for 1 event. A better implementation of postTwistedEvent would probably check the return value of post and go into a block/sleep loop until it's able to post.


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.

Yes it is called from another thread. The event functions are thread safe. As stated above, the only real addition would need to be to postTwistedEvent so that it will block if the event queue is full. Either that, or refactor pygame so it can take advantage of better SDL event handling practices, but that isn't my goal.


I don't need pygame/twisted integration. I didn't write threadedselectreactor for pygame. I wrote it for foreign event loop integration. It does exactly what it needs to do exactly how it should do it. The pygame example is not optimal, but it's enough to show how it can be done, and someone else can take it to the next level (without having to touch twisted) -- that was the point.

-bob