Topics

1

Window / Multithreading in X11 Window implementation [patch]

« on: April 17, 2009, 04:42:01 am »

Hi there,

I've started using SFML for window and GL context creation, as it's nice to have a OO API for this stuff. Recently I've found a problem when trying to execute something like this pseudocode:

Code: [Select]


Thread:
    new sf::Window(...);
    /* ... */

Main:
    t0 = new Thread();
    t1 = new Thread();

    t0.join();
    t1.join();


Sometimes the code works, sometimes it terminates with an assertion inside Xlib. The problem is that all sf::Window's share a connection to the X server (the display), and concurrent use of the same connection is not supported by the X11 protocol. I don't have much experience with X programming, but I don't see any advantage in having a global connection for all windows. If the user wants more than one window, he should accept the overhead of more than one connection to the X server (which I would guess is not significant).

OpenGL contexts can still share resources, but the user must treat window creation as a critical section (due to the global context inside SFML) or else contexts won't be shared properly. Thus:

Code: [Select]


Thread:
    window_creation_mutex.lock();
    new sf::Window(...);
    window_creation_mutex.unlock();
    /* ... */

Main:
    t0 = new Thread();
    t1 = new Thread();

    t0.join();
    t1.join();


I'm posting this in the forums as it seems the sourceforge tracker is not being followed. I've attached a patch to the sourceforge page that gives all windows a unique connection to the X server ( https://sourceforge.net/support/tracker.php?aid=2769876 ). The patch is against the current trunk revision 1076. (Note: the patch also implements the fix to this artifact: http://sourceforge.net/support/tracker.php?aid=2719693 )

Looking at the sourceforge page it seems development is happening only on the sfml2 branch. Looking at sfml2 X11 Window implementation there is heavy work being done (DisplayRef) to make the X server connection unique, causing the same threading problems. I'm willing to write a patch against the sfml2 branch (removing the global state DisplayRef), if this branch is stable enough for use.

Sorry for the long post :]