Dear Experts, The boost::thread documentation says: Just as the lifetime of a file may be different from the lifetime of an iostream object which represents the file, the lifetime of a thread of execution may be different from the thread object which represents the thread of execution. In particular, after a call to join(), the thread of execution will no longer exist even though the thread object continues to exist until the end of its normal lifetime. The converse is also possible; if a thread object is destroyed without join() first having been called, the thread of execution continues until its initial function completes. That's fine, but it's not what I'm looking for right now. Can anyone point me to some code - perhaps adding a layer on top of boost::thread - that ties object lifetime to thread lifetime in some way? (I'm imagining a dynamically-allocated object the deletes itself when the thread's initial function terminates, and that kills the thread if it (the object) is deleted first.) 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. My guess is that this could be done in just a few lines of code, but there are probably lots of race conditions to worry about. Any suggestions anyone? Cheers, --Phil.
On 10/25/05, Phil Endecott
Dear Experts,
The boost::thread documentation says: [...snip...] 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. You could also use boost::call_once to "fire and forget"
Phil Endecott wrote:
That's fine, but it's not what I'm looking for right now. Can anyone point me to some code - perhaps adding a layer on top of boost::thread - that ties object lifetime to thread lifetime in some way? (I'm imagining a dynamically-allocated object the deletes itself when the thread's initial function terminates
That's possible - the thread could certainly delete its object at the end of its lifetime. However if anyone else had a pointer to it, it would be asking for access-of-deallocated-memory troubles. You could avoid this via some some shared_ptr/weak_ptr mechanism, but then you've moved away from the thread-lifetime == object-lifetime idea.
and that kills the thread if it (the object) is deleted first.)
boost::thread doesn't give you a way to kill a thread, because it's almost always a bad idea. What about desctructors for objects that were on the thread's stack? Operations that it may have been halfway through completing? (including memory allocation - you could be corrupting your global heap) I'm not saying it's always possible to have a thread exit nicely - but in those circumstances, I begin thinking about moving that thread's work into a seperate process (which you can usually kill without repercussions).
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.
Why don't you create them and delete them immediately? The thread will continue to run, even if the object is destroyed (as you've noticed ;-)
participants (3)
-
Aaron Griffin -
Pete Chapman -
Phil Endecott