SFML community forums
Help => General => Topic started by: prchakal on September 19, 2012, 05:58:19 am
-
Hi,
I create a sample code to illustrate my problem:
void threadMethod()
{
while(true){}
}
int main()
{
sf::Thread thread(&threadMethod);
thread.launch();
return EXIT_SUCCESS;
}
When thread start, the process stop/lock until threadMethod exit (in this example, never).
Why it happen if thread is another "process"? The correct is thread start and program finish on "return EXIT_SUCESS". No?
-
The destructor of sf::Thread calls the wait() function -- which waits for the thread to finish. Read the doc and tutorial carefully.
-
So,
I see it yesterday, if i extend it and rewrite destructor solve, right?
-
if i extend it and rewrite destructor solve, right?
No, of course not. Use sf::Thread the way it is supposed to be used.
That is, wait for your threadMethod() to finish normally.
-
In other words, sf::Thread won't let your program end if a thread is still running.
But what are you trying to do? And why is it a problem for you?
-
Hi Laurent,
In that my program with V8, i use scripts to update "player1" and "player2", but i need run it in threads and leave the SFML render in main thread.
I need launch one thread for each player without block main thread that will render everything.
Imagine 100 players and each player a new thread that will update this players.
Is the same concept of ROBOCODE (http://robocode.sourceforge.net/).
-
I use scripts to update "player1" and "player2", but i need run it in threads and leave the SFML render in main thread.
I need launch one thread for each player without block main thread that will render everything.
Keep in mind when updating and rendering happen in different threads you might run into the problem, that not every entity is up to date with the same data while you draw it already. E.g. you move 100 players one pixel to the left while on the same time you draw them. The generated image might be that some of the players already moved that one pixel while others are still on the same position...
Apart from that you might run into race conditions and other nasty stuff, if you don't handle mulithreading correctly. ;)
Btw the main thread doesn't get blocked as long as it has to do something, but in the posted example the main function reached it's end, thus it tried to destroy the sf::Thread objects, but since they were still running wait() is called in the destructor.