Problem with threads on Linux

[MaxV37]

I am trying to separate the event thread and the rendering thread in my game.

To try it out, I ran the following code from the SFML tutorials :

void renderingThread(sf::RenderWindow* window)
{
    // the rendering loop
    while (window->isOpen())
    {
        // draw...

        // end the current frame
        window->display();
    }
}

int main()
{
    // create the window (remember: it's safer to create it in the main thread due to OS limitations)
    sf::RenderWindow window(sf::VideoMode(800, 600), "OpenGL");

    // deactivate its OpenGL context
    window.setActive(false);

    // launch the rendering thread
    sf::Thread thread(&renderingThread, &window);
    thread.launch();

    // the event/logic/whatever loop
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) window.close();
        }
    }

    return 0;
}
 

However, after compiling and running this program, I get this error :

Code: [Select]

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
test: xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Aborted (core dumped)

I read in this topic that this problem can be solved by calling XInitThreads(), but that it is a bad solution, because not only is it not cross-platform, but it adds overhead and might slow down everything.

It is explicitly stated in the tutorials to manage events in the main thread, which is the case here, so I think it is a bit misleading to promote a solution that is not cross platform in the tutorials.

I also tested it with std::thread and i get the same results.
I sometimes get this error message repeated multiple times : `Error while creating udev enumerator`, so I believe the problem comes from SFML.

For information, my OS is manjaro Linux, and I use SFML 2.4.2.

[Laurent]

It may be bad, not cross-platform, add overhead and slow-down everything, but this is, as far as I know, the only solution when dealing with X11. By the way, all this crap explains why it is not done by default inside SFML

[CytraL]

I have the same issue... but loading assets in a thread:

When do this:

Code: [Select]

sf::Thread thread(&CAssetManager::load, m_pAssetManager);
thread.launch();

Get this:

Code: [Select]

[59761a92][CGame]: Initializing game...
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
cherryjam_d: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

System Info

Code: [Select]

- OS: Mint 18.2 sonya
- Kernel: x86_64 Linux 4.10.0-27-generic
- Resolution: 2944x1080
- DE: Cinnamon 3.4.4
- WM: Muffin
- CPU: Intel Core i7-3770 CPU @ 3.9GHz
- GPU: GeForce GTX 970
- RAM: 3364MiB / 11971MiB


If i try to run the program several times.... some times it runs without any error. O_o
The same code (thread stuff) with "SFML 2.3v5" (version installable via apt-get) works fine... but with SFML 2.4.2 this bug appears :/

I also had to apply this patch to compile the library (SFML v2.4.2): https://en.sfml-dev.org/forums/index.php?topic=20638.0

[Laurent]

SFML 2.x (don't remember the exact versions) was using XCB, we reverted back to Xlib recently for other reasons.

[binary1248]

Just FYI: In both code excerpts provided above, access to the SFML window doesn't seem to be protected by any mutex even though it is used across multiple threads. This will not only lead to problems in SFML (sf::Windows aren't implicitly thread safe, no matter what OS), but will cause data races to happen in the X implementation as well, which is what is happening leading to the abort. Make sure that "things" are done on the window in a single thread at a time (which is the way it should be regardless of the X limitation anyway) and X should also stop complaining.

[barnack]

Here are 2 bits of little knowledge from a new comer.
That's so bad. Using a thread to draw some objects, the same objects which values can be changing in the meanwhile in a totally different thread, without using any ward.
I've never done something thread-intensive in c++, but i've done so in c, and i can tell you this totally open approach is way too much open and unsafe. You'd rather have to add some mutexes here and there to prevent yourself from drawing something which is changing in the meanwhile.

e.g. an event's evaluation includes updating something's x and y coordinates. In the function you can think about it as an instant-action. But in assembly level that action is split into many instructions.
Now, it can happen you draw that object in the same "moment" the other thread is changing it, leading to weird things happening, if not errors.
For example, your "update" thread has completed the update of your object's x coordinate, then the task scheduler pauses that thread, the draw thread goes on drawing your object into its new x and its old y, then the task scheduler restores your update thread, and it finally updates the y coord.
Now, this one was a really optimistic one, and still a huge sync problem. That's why, with multi-threading, you WANT to spam mutexes wherever you're dealing with any kind of data which is shared between two or more threads. (sometimes leading yourself to understand that in many cases a second thread will just reduce overall performances).