Re: [Pysdl-devel] Threads and events

[Ray K. <rh...@ne...>]

Jan Ekholm wrote:
> 
> On Fri, 6 Oct 2000, Pete Shinners wrote:
> >as far as handling threads, you'll find pysdl does not support
> >the SDL threading routines. this is because python already
> >comes with great crossplatform threading. (also with it's own
> >semaphores/mutexes/locks). your best bet is to peek at the
> >'Threading' module
> 
> ...which was exactly the page I had in front of me. I have no problems
> using threads, just the general thread-safeness of the system is
> interesting. And problems with that tend to be hard to spot, very hard to
> debug and otherwise just a PITA.

Actually, at least for version 1.5.2, python threading uses a single 
lock for the interpreter, so only one thread of python code will run
at a given time. When you enter a blocking call (like read, select,
etc) the C code for that function has to release the interpreter lock.

Since pysdl doesn't do this, it probably won't play nice with 
threading. It's fairly easy to implement (I did it in the python
binding for SDL_gui) and works quite well. You basically have to 
save the thread state before you block (PyEval_SaveThread), then do 
your blocking call, then restore the thread state 
(PyEval_RestoreThread).

This should at least be put in the SDL_WaitEvent wrapper function.
 
> >because the event objects are written as C extensions, it is
> >not easy to modify them much from the python side. your idea
> >for a global user-data queue sounds like the best idea for now.
> 
> Yep, it should also be quite simple, as there are ready synchronized
> queues etc.
> 
> >just a note here, you might have good results with the 'select'
> >module. this works on windows and unix. it allows you to do
> >asynchronous networking on a single thread. it even works well
> >with multiple sockets. i've never looked into it too far, but
> >i've heard good things about it. anyways if the threading gets
> >too tricky, it might be a good alternative.
> 
> I don't want to use that one. I'm more confident with splitting up my game
> in as many logical modules as possible, and threads are a good idea of a
> logical module in my world. Sure, they add complexity and reduce speed
> (maybe), but will end up making my main event loop simpler. I can then
> just sit an wait for some event to occur (user does something, packet
> arrives etc).
> 

As it works out (and has been discussed on the SDL mailing list) 
threading in a game doesn't really work all that well on a single
CPU system. Mainly because the rendering thread can consume 100% cpu
all by itself, which means it will be interrupted by the scheduler
when an event happens, which causes choppiness in the display.

There's more to it, but that covers the common case.

-Ray