Ok, thank you I will look at those resources. I also purchased an account with the ACM digital library so have access to many of the sources cited in the boost doc. One question I do have though. I am creating a functor object like so (ignore the CLI crap, it isn't relevant): class connection_thread_proc { gcroot<TcpListener ^> server; boost::shared_ptr<Listener> listener; public: connection_thread_proc(boost::shared_ptr<Listener> const& l, TcpListener ^ t) : server(t), listener(l) {} void operator() () { listener->run(server); } }; Now later I do something like so: void start_new_connection() { ... boost::thread connection_thread(connection_thread_proc(l,s)); } Originally I assumed that there would be problems with this since my thread object goes out of scope so I figure the connection_thread_proc it holds should be destroyed along with it...and with it important objects like the listener and the tcp connection. So I was working on this convoluted way to store threads and check their state...which boost doesn't support out of the box it looks like and I was going to have to add yet another wrapper to the pile...so I decided to try and see if it did indeed explode and it doesn't. The question is, am I looking at undefined behavior that happens to work correctly or is this by design? I would like to trust that this will continue working as I add behaviors.