Jump to content
  • Advertisement
KKTHXBYE

initialize std::thread

Recommended Posts

How can i create a thread that executes a function (void) in a class, cause

void foo() {}

int main()
{
std::thread first (foo); 
}

works

 

but
 

struct TTCPServer
{
void foo() {}
void CreateThread()
{
std::thread first (foo); 
}
};

 

doesnt even compile

Edited by Cat's machete

Share this post


Link to post
Share on other sites
Advertisement
#include <functional>
#include <thread>

struct TTCPServer {
    void foo() {}
    void CreateThread() {
        std::thread first(std::bind(&TTCPServer::foo, this)); 
    }
};

int main() {};

https://wandbox.org/permlink/6IODSGQnzTtm5QhU

"this" is always passed as an implicit argument of the member method. You must bind all arguments of the member method.

Edited by matt77hias

Share this post


Link to post
Share on other sites

yeah i just went here to write the same thing i figoured that out myself thanks man

listen_and_accept_finished = false;

std::thread ListenThread(&TTCPWindowLayerServer::ListenAndAccept, this);

 

however using your code or mine makes my app to crash

theres an int i increment each time thread loop executes

 

void ListenAndAccept()
{
	while (!listen_and_accept_finished)
	{
		Port = Port + 1;
		continue;
    }
}

and it just crashes after few iterations

 

i dont even use int Port; anywhere else except during class constructor to define it as 0

listen_and_accept_finished isnt used anywhere else than in this loop too

 

i get

Fatal signal 6 (SIGABRT)
 

it may seem that android doesnt like threads...

Share this post


Link to post
Share on other sites
30 minutes ago, Cat's machete said:

and it just crashes after few iterations

You only invoke CreateThread once, I suppose? I am not really into <thread>, but shouldn't listen_and_accept_finished (and Port) be volatile, since they will be modified outside the thread? Though in any case, I am not sure why it would crash.

#include <functional>
#include <iostream>
#include <thread>

struct TTCPServer {
    volatile bool listen_and_accept_finished = false;
    volatile int port = 0;
    
    void ListenAndAccept() {
       while (!listen_and_accept_finished && port < 10) {
           std::cout << port++ << std::endl;
       }
    }
    
    std::thread CreateThread() {
        return std::thread(std::bind(&TTCPServer::ListenAndAccept, this)); 
    }
};

int main() {
    TTCPServer server;
    server.CreateThread().join();
};

https://wandbox.org/permlink/A8cZoSbv6wM9BST8

Edited by matt77hias

Share this post


Link to post
Share on other sites

funniest thing is whenever i add ListenThread.join(); and create exit condition so thread actually quits it doesnt crash anything.

Share this post


Link to post
Share on other sites
5 minutes ago, Cat's machete said:

funniest thing is whenever i add ListenThread.join(); and create exit condition so thread actually quits it doesnt crash anything.

As I understand you correctly, you execute something like my code above without invoking "join" on the "std::thread"? In this case your main thread will finish, destroy the TTCPServer on the stack which causes the captured "this" pointer of your std::thread to become invalid, resulting in undefined behavior.

Edited by matt77hias

Share this post


Link to post
Share on other sites

this is why i do this:

TTCPWindowLayerServer * srvtcp = new TTCPWindowLayerServer();
    srvtcp->CreateServer(0);

 

 

i dont want to call join cause i don't want the main thread to be paused at all,

 

however it may seem that android automatically crashes my app, since i think it thinks the UI Thread is being suspended, thus how is this even possible, when i spawn a thread so it shouldnt matter from which place i spawn it, it should independly even when im creating server class in that ui thread, but if it is so, then i just grab my pc and throw it into river.

looks like you cant stall ui thread with some standard function even for 20 seconds, but you cant stall it with a thread for even a microsecond., and my app base is always dependnt on ui thread since i call onTap(x, y) from java to execute cpp code.....

 

either i thro pc and phones to the river or make a bypass by using join and somehow proceed with stalled threads. giving up seems easier

Edited by Cat's machete

Share this post


Link to post
Share on other sites
27 minutes ago, Cat's machete said:

i dont want to call join cause i don't want the main thread to be paused at all,

I know, but in the end you want your application including all its threads to be terminated properly. I just added it to have a correct example. :)

Edited by matt77hias

Share this post


Link to post
Share on other sites

i have read cpp reference more carefully and found that detach does not kill the thread but makes it independent from creator thread, so this is my saint graal

 

Detaches the thread represented by the object from the calling thread, allowing them to execute independently from each other.

Both threads continue without blocking nor synchronizing in any way. Note that when either one ends execution, its resources are released.

After a call to this function, the thread object becomes non-joinable and can be destroyed safely.

 

 

jeez i almost threw all my phones down the river ;p

Share this post


Link to post
Share on other sites

It might work at the moment, but as soon as your thread does something interesting, it will likely need to communicate with other parts of your program.

Depending on how that is implemented, you could re-introduce the crashes.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!