The actual application is a sort of daemon; a main loop accepts tcp connections, and creates a new thread to handle each one. It normally wants to "fire and forget" these threads, and I imagine it creating them with new() and then letting them dangle, until they eventually terminate and delete themselves.
I may be missing something here, but if thread lifetime and object lifetime are not tied, why not create the object on the stack (as part of an accept() loop, using the tcp connection example). The stack based object will be destroied each loop, but the thread itself will continue to exist until it ends.
Yes, that's true. I suppose I'm thinking this way because I'm also imagining that I can subclass this new Thread class to add state, e.g. class DaemonThread: public Thread { private: ... per-connection state ... public: DaemonThread(int connection_fd); }; void mainloop() { while(1) { int fd = accept_connection_on_socket(); DaemonThread* handler = new DaemonThread(fd); } } If instead I put the state in another object that's created within the thread's initial function then I can afford for the actual thread object to expire immediately. There must be lots of ways to do this sort of thing.
You could also use boost::call_once to "fire and forget"
I think I know what call_once() does but I don't see how it helps. Can you elaborate? Cheers, --Phil.