[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