Re: [Pysdl-devel] Threads and events

[Jan E. <ch...@in...>]

On Sat, 7 Oct 2000, Ray Kelm wrote:

>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.

Urgh. Well, I'll try and see anyway. I use 2.0, so there may be some
changes. Personally I'd think it's silly for all threads to be suspended
just because one thread does some blocking call. If it doesn't work out
I've at leats learnt something about Python threading in the process.

>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.

Yep, you may be right. But then, I assume they were discussing games where
there always is something to do, such as play music, render a complex 3D
scene, run AI etc. I'm not doing that kind of game, but instead one that
will spend most of its time waiting for the user to do something, or a
packet to arrive from the opponent. If I needed ultimate performance I
would most likely go with C/C++, as Python is not a real option in these
causes (well, if you don't have the entire game as a single C
extension).

But, thanks for your tips, now I know that this time I *may* be able to
blame the 'system', and not my own bugs if the threads don't work... :-)

By the way, does anyone know of a good way to get PySDL key-events
translated so that I can get a string/character with the pressed key? Such
as when K_SPACE is triggered I get a nice string: " "? I need this for
reading text from the player. Currently I have one big dictionary which
maps K_* to some string, or the empty string if there is no real
string-representation of the key, such as K_F1. Some other keys also need
to be treated differently, such as K_BACKSPACE. Any ideas? Is there
something I've overlooked so far?

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams