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 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.
