I'm using sf::Threads in my program and I have it running in windows, but now I'm porting it over to windows. I already have the build target made and it successfully compiles, and runs right up until I try to launch the game, which uses threads. Then my objects are successfully constructed, but then it says that:
[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.
NumberHunterGame: xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
I'm using SFML 2.1 in my program grabbed directly from the Fedora repos.
I was reading a forum thread about passing my sf::RenderWindow as a pointer to my rendering thread func, but I don't think that will make any difference as I made my sf::RenderWindow instance a global. I tried calling XInitThreads() at the beginning of main, but that causes more problems then it solves.
The whole file is available here: https://github.com/HSchmale16/NumberHunterGame/blob/master/main.cpp
Edit: I've been asked about how I have the threads set up and this is the general design.
I create the sf::RenderWindow in the main thread then deactivate in the main thread then launch the rendering thread. After that I launch the game event handling thread. The only thing the main thread handles is the window events, so it should be thread safe. The SFML docs say that I can handle the window events in the main thread while using another thread to render.
Related
I'm playing around with SLD2 and I've got a somewhat working game. It works great on Linux/Windows, but I'm getting an exception on macOS.
I've done input handling in a separate thread, basically it just polls for user input and then does calculations/moves sprites around etc. My problem is that on macOS it seems that the library is compiled in a way that when you call SDL_PollEvent, SDL_WaitEvent or SDL_HasEvents it calls SDL_PumpEvents from within itself, which can only be called from the main thread.
Is there a way to get the events without the functions calling SDL_PumpEvents? (I call that in main thread on every iteration, so it really isn't needed)
I'm on some c++ mobile product, but I need my apps main thread is still running without any blocking when doing some heavy work on the background thread and run back on main thread. But I realized there is no runOnMainThread/runOnUIThread in c++ thread api. I trying to figure it out the issue and found that need to depend library, or create your own thread event queue. Although it is good, but i am thinking to have a behavior which can runOnUIThread.
How it does not work: the mentioned library creates a timer, installs a SIGALRM signal handler and dispatches queued tasks when signals are fired. This allows tasks being processed on the main thread even when it is busy. However POSIX permits only a small set of async-signal-safe functions to be invoked inside of signal handler. Running arbitrary с++ code inside of signal handler violates that restriction and leaves application in hopelessly doomed state.
After some research and development, I've created a library called NonBlockpp
it is a small c++ library to allow c++ mobile application able to process the heavy and time consuming task on background and back to Main thread again, It’s been tested and fired the main thread event.
It also allow to save the tasks and fire them later, all the task has no blocking each other and thread safety.
How it works:
If you found any query or suggestion, please don't hesitate to raise an issue and we can discuss it together.
The project has rectify from signal to pollEvent due to signal handler might not be safe to use.
Please take a look the new changed.
NonBlockpp
Usage
I have multi-thread application, in which main thread falls on some event. Thread falls on SIGSEGV signal. Other threads continue work. My question is how to dig maximum information about failed thread to analyse it later? Starting with the question of how to find out which of the threads fell.
Really it is actual ussie which arose when working with qt 4.7 signal/slot system + webview widget. It's interesting that on version 5 everything is fine.
I will be happy for any idea. I'm working on ubuntu, qt project.
Having some confusion over what counts as the "Main" thread in this situation.
I have QT running in my first thread which is blocking. I want to run SDL2 in a secondary thread, with all calls and initilisation isolated to this thread.
Will this allow SDL2 to run correctly and stable as the Documentation states it needs to be in the main thread? Also this question SDL2 two windows in different threads states you can't use certain SDL2 functions outside the "main" thread.
In this case is the main thread, as far as SDL2 is concerned, the first thread containing QT, or the second thread SDL2 was initilised in?
This is just a guess, but in linux the concept of a "main thread" is the first thread in a process. Here's how to see if a thread is the main thread: Check if current thread is main thread
So to answer your question, you can't have QT running as the first thread and SDL2 running as the second. You'll either need:
Two processes. Then, each is running a main thread
Run SDL as the first process (the main thread) and QT as a subthread (if QT allows for this)
I'm somewhat confused and wondering if I've been misinformed, in a separate post I was told "New threads are only created when you make them explicitly. C++ programs are by default single threaded." When I open my program that doesn't explicitly create new threads in ollydbg I noticed multiple times that there are often 2 threads running. I wanted to understand how the message loop works without stopping up execution, the explanation I got was very insufficient at explaining how it works.
Does the message loop create a new thread or does it take up the main thread? If it takes the main thread does it do so after everything else has been executed regardless of code order? If it doesn't do this but still takes up the main thread does it spawn a new thread so that the program can execute instead of getting stuck in the message loop?
EDIT: Solved most of my questions with experimentation. The message loop occupies the main thread and any code after the code:
while (GetMessage (&messages, NULL, 0, 0))
{
TranslateMessage(&messages);
DispatchMessage(&messages);
}
return messages.wParam;
Will not execute unless something special is done to cause it to execute because the program is stuck in the message loop. Putting an infinite loop in a window procedure that gets executed causes the program to crash. I still don't understand the mystery of the multiple threads when in olly to the degree I would prefer though.
Perhaps the place to start is to realize that "the message loop" isn't a thing as such; it's really just something that a thread does.
Threads in windows generally fall into one of two categories: those that own UI, and those that do background work (eg network operations).
A simple UI app typically has just one thread, which is a UI thread. For the UI to work, the thread needs to wait until there's some input to handle (mouse click, keyboard input, etc), handle the input (eg. update the state and redraw the window), and then go back to waiting for more input. This whole act of "wait for input, process it, repeat" is the message loop. (Also worth mentioning at this stage is the message queue: each thread has its own input queue which stores up the input messages for a thread; and the act of a thread "waiting for input" is really about checking if there's anything in the queue, and if not, waiting till there is.) In win32 speak, if a thread is actively processing input this way, it's also said to be "pumping messages".
A typical simple windows app's mainline code will first do basic initialization, create the main window, and then do the wait-for-input-and-process-it message loop. It does this usually until the user closes the main window, at which point the thread exits the loop, and carries on executing the code that comes afterwards, which is usually cleanup code.
A common architecture in windows apps is to have a main UI thread - usually this is the main thread - and it creates and owns all the UI, and has a message loop that dispatches messages for all of the UI that the thread created. If an app needs to do something that could potentially block, such as reading from a socket, a worker thread is often used for that purpose: you don't want the UI thread to block (eg. while waiting for input from a socket), as it wouldn't be processing input during that time and the UI would end up being unresponsive.
You could write an app that had more than one UI thread in it - and each thread that creates windows would then need its own message loop - but it's a fairly advanced technique and not all that useful for most basic apps.
The other threads you are seeing are likely some sort of helper threads that are created by Windows to do background tasks; and for the most part, you can ignore them. If you initialize COM, for example, windows may end up creating a worker thread to manage some COM internal stuff, and it may also create some invisible HWNDs too.
Typically the thread that starts the program only runs the message loop, taking up the main thread. Anything not part of handling messages or updating the UI is typically done by other threads. The additional thread that you see even if your application doesn't create any threads could be created by a library or the operating system. Windows will create threads inside your process to handle things like dispatching events to your message loop.