Threading PySFML (Tank, remi, anyone familiar with GIL ? )

[Kaoron]

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) :

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.

[bastien]

I guess that in a real life example one would use proper synchronization primitives and this would remove the need for that sleep.
Normally the interpreter releases the lock regularly so that another thread has the chance to run. I don't know if the fact that his thread sucked all CPU time comes from bad luck, poor GIL behavior or from a bug in PySFML.

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.

You mean thread-safe? To me it doesn't look like PySFML should bother with this. In my opinion the user should consider whether he really needs parallelism, and release the lock himself as needed during computations, after profiling his app.

But I may wrong, since I've never used the GIL. For example, what happens if a user thread starts drawing while you released the lock and are executing self->obj->Display()?

[Iknow Atal]

I had the same problem, turns out the python devs made a module named "multiprocessing" basically it run a subprocess with your code in it eliminating the need for threads really, heres an example:

Code: [Select]


from multiprocessing import Process

def Example:
    print "Example text"

if __name__=='__main__':
    p=Process(target=Example, args=())
    p.start()
    p.join()


p.s. sync primitives such as Pipes and Queues are included in the module, check the documentation!