1
Python / Threading PySFML (Tank, remi, anyone familiar with GIL ? )
« on: April 15, 2010, 01:42:29 am »
This is a follow-up of a thread (!) in the french forum :
http://www.sfml-dev.org/forum-fr/viewtopic.php?t=2454
Basically, it says "PySFML locks all threads up".
I first investigated on how to work around this limitation on the python side, resulting in the use of sleep() inside the PySFML thread - maybe any IO function could do the trick here.
Now, I wish to make the wrapper more thread-friendly, there comes the GIL, the (in)famous Global Interpreter Lock. To let python threads execute while pysfml is doing time consuming IO stuff (like say... displaying things), the module has to release the lock so it is on it's own, then reacquire it when it wants to discuss with python again.
I made a test wrapping the Display call between python ALLOW_THREADS macros, but I don't have a very deep understanding on how the GIL works, and how extension modules can be safely threaded.
Here is the trick (in Window.cpp) :
Pretty simple, isn't it ? Yet maybe awfully stupid regarding concurrent programming design, so that's the very rationale of this topic : let's discuss it to make sure what's the way to go.
http://www.sfml-dev.org/forum-fr/viewtopic.php?t=2454
Basically, it says "PySFML locks all threads up".
I first investigated on how to work around this limitation on the python side, resulting in the use of sleep() inside the PySFML thread - maybe any IO function could do the trick here.
Now, I wish to make the wrapper more thread-friendly, there comes the GIL, the (in)famous Global Interpreter Lock. To let python threads execute while pysfml is doing time consuming IO stuff (like say... displaying things), the module has to release the lock so it is on it's own, then reacquire it when it wants to discuss with python again.
I made a test wrapping the Display call between python ALLOW_THREADS macros, but I don't have a very deep understanding on how the GIL works, and how extension modules can be safely threaded.
Here is the trick (in Window.cpp) :
Code: [Select]
static PyObject *
PySfWindow_Display(PySfWindow *self)
{
Py_BEGIN_ALLOW_THREADS
self->obj->Display();
Py_END_ALLOW_THREADS
Py_RETURN_NONE;
}
Pretty simple, isn't it ? Yet maybe awfully stupid regarding concurrent programming design, so that's the very rationale of this topic : let's discuss it to make sure what's the way to go.