Hi, ----- Original Message ----- From: "cowwoc" To: Sent: Wednesday, October 28, 2009 7:33 PM Subject: Re: [Boost-users] at_thread_exit() never getting called

I think https://svn.boost.org/trac/boost/ticket/2739 prevents it from working.

Gili

Steven Watanabe-4 wrote:

...

AMDG

cowwoc wrote:

...

I am registering boost::this_thread::at_thread_exit() against one of my threads. When the main thread exits using "return 0" the at_thread_exit hook never gets invoked. Is this normal?

It's supposed to work for the main thread...

For me yes, but it dosn't works. The example attached to the ticket show the problem.

...

...

Is there a way to hook the main thread shutting down?

On windows you can use on_thread_exit().

The patch worked when I summited it. Anthony, I've see that you have started to integrate the patch for the thread attributes. Do you plan to integrate this patch also? Thanks, Vicente

Hi, ----- Original Message ----- From: "Anthony Williams" To: Cc: Sent: Thursday, October 29, 2009 9:49 AM Subject: Re: [Boost-users] at_thread_exit() never getting called

"vicente.botet" writes:

...

...

...

cowwoc wrote:

...

I am registering boost::this_thread::at_thread_exit() against one of my threads. When the main thread exits using "return 0" the at_thread_exit hook never gets invoked. Is this normal?

If you call exit() then thread exit handlers are not called. "return 0" in main() is the same as calling exit(0), so thread exit handlers are not called.

...

Anthony, I've see that you have started to integrate the patch for the thread attributes. Do you plan to integrate this patch also?

No.

If you call pthread_exit(0) from main() then thread exit handlers *will* be called. Of course, this doesn't exit the program until all other threads have terminated, whereas "return 0" kills the other threads.

Unfortunately, after rereading the patch I proposed, I recognize the patch don't works if there are other external threads in the programm as in patch stores only the last external thread context. Calling pthread_exit(0) on a pthread thread is natural, but the main thread is no created as a pthread, so this call is not portable. Do you think that we need a portable function boost::exit that will call to pthread_exit? With the current implementation we don't have any error when we call at_thread_exit on an external thread. This has as consequence that the destructors of the TSS are not called. This is a severe restriction from my point of view. Do you have a portable solution? Best, Vicente

Bugzilla from anthony.ajw@gmail.com wrote:

"vicente.botet" writes:

...

...

...

cowwoc wrote:

...

I am registering boost::this_thread::at_thread_exit() against one of my threads. When the main thread exits using "return 0" the at_thread_exit hook never gets invoked. Is this normal?

If you call exit() then thread exit handlers are not called. "return 0" in main() is the same as calling exit(0), so thread exit handlers are not called.

...

Anthony, I've see that you have started to integrate the patch for the thread attributes. Do you plan to integrate this patch also?

No.

If you call pthread_exit(0) from main() then thread exit handlers *will* be called. Of course, this doesn't exit the program until all other threads have terminated, whereas "return 0" kills the other threads.

Anthony

Anthony, The documentation is far from obvious on this point. It just reads: "This copy is invoked when the current thread exits (even if the thread has been interrupted)." Source: http://www.boost.org/doc/libs/1_40_0/doc/html/thread/thread_management.html#... I expect the function to get invoked if the thread exits for *any* reason, not just because the documentation says so but also because it's what I want from a coding point of view. Thanks, Gili -- View this message in context: http://www.nabble.com/at_thread_exit%28%29-never-getting-called-tp26053513p2... Sent from the Boost - Users mailing list archive at Nabble.com.

Bugzilla from anthony.ajw@gmail.com wrote:

cowwoc writes:

...

The documentation is far from obvious on this point. It just reads: "This copy is invoked when the current thread exits (even if the thread has been interrupted)."

Source: http://www.boost.org/doc/libs/1_40_0/doc/html/thread/thread_management.html#...

I expect the function to get invoked if the thread exits for *any* reason, not just because the documentation says so but also because it's what I want from a coding point of view.

OK, I'll update the documentation.

Anthony

I'd rather you fix the undesirable behavior instead... Gili -- View this message in context: http://old.nabble.com/at_thread_exit%28%29-never-getting-called-tp26053513p2... Sent from the Boost - Users mailing list archive at Nabble.com.

cowwoc writes:

Bugzilla from anthony.ajw@gmail.com wrote:

...

cowwoc writes:

...

The documentation is far from obvious on this point. It just reads: "This copy is invoked when the current thread exits (even if the thread has been interrupted)."

Source: http://www.boost.org/doc/libs/1_40_0/doc/html/thread/thread_management.html#...

I expect the function to get invoked if the thread exits for *any* reason, not just because the documentation says so but also because it's what I want from a coding point of view.

OK, I'll update the documentation.

I'd rather you fix the undesirable behavior instead...

OK, what is your desired behaviour in these circumstances? (1) main() thread uses at_thread_exit() and then main() returns (2) main() thread uses at_thread_exit() and calls exit() (3) main() thread uses at_thread_exit(). *Another* thread calls exit() (4) *another* thread uses at_thread_exit(). main() returns (5) *another* thread uses at_thread_exit(). main() calls exit() (6) *another* thread uses at_thread_exit() and then calls exit() Note that returning from main() is the same as calling exit(), and abruptly terminates all threads. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

cowwoc wrote:

Anthony Williams-4 wrote:

...

OK, what is your desired behaviour in these circumstances?

(1) main() thread uses at_thread_exit() and then main() returns

(2) main() thread uses at_thread_exit() and calls exit()

(3) main() thread uses at_thread_exit(). *Another* thread calls exit()

(4) *another* thread uses at_thread_exit(). main() returns

(5) *another* thread uses at_thread_exit(). main() calls exit()

(6) *another* thread uses at_thread_exit() and then calls exit()

Note that returning from main() is the same as calling exit(), and abruptly terminates all threads.

Hi Anthony,

For all cases mentioned above I would expect the shutdown hook to get invoked.

The at_thread_exit hooks are invoked in the context of the thread. When exit is called, the threads are executing something, and it is not possible to make them stop whatever they are doing in order to execute the at_thread_exit hooks (and it would be a bad idea were it possible, because the thread state could be inconsistent and cause a crash in the hook.) It's possible to execute the at_thread_exit hooks just for the thread that called exit(), but this is inconsistent and effectively duplicates atexit.

cowwoc wrote:

Peter Dimov-5 wrote:

...

The at_thread_exit hooks are invoked in the context of the thread. When exit is called, the threads are executing something, and it is not possible to make them stop whatever they are doing in order to execute the at_thread_exit hooks (and it would be a bad idea were it possible, because the thread state could be inconsistent and cause a crash in the hook.)

Peter,

Are you saying that if I register shutdown hooks for threads 1, 2 and 3 and invoke exit() from thread 3 the current behavior of at_thread_exit() would cause the shutdown hooks to all get invoked by thread 3 while thread 1 and 2 are still executing?

I'm not sure what the current behavior is, but in this scenario, no hooks should be executed. I think that this is consistent with how TSD destructors work under POSIX, but I can't test this at the moment.

cowwoc wrote:

Unless I missed something, I don't think that the scenario you propose would work for my use-case. Basically, I've got a thread that runs in an endless loop until the program shuts down. When the program shuts down, I want it to clean up some resources cleanly. The way I've done this is by registering a at_thread_exit() hook that causes the aforementioned thread to shut down cleanly (breaking out of the endless loop) thereby allowing it to clean up its resources cleanly.

You can't use an at_thread_exit hook registered from within a thread to shut down this same thread; this is circular. If you want to shut down a thread when exit() is called or when main returns, use atexit, or a destructor of a static variable. I don't see how at_thread_exit could help in this case, although of course I may be misunderstanding something.

cowwoc wrote:

Peter Dimov-5 wrote:

...

You can't use an at_thread_exit hook registered from within a thread to shut down this same thread; this is circular. If you want to shut down a thread when exit() is called or when main returns, use atexit, or a destructor of a static variable. I don't see how at_thread_exit could help in this case, although of course I may be misunderstanding something.

Part of the problem is that neither atexit() or at_thread_exit() explicitly specify which thread the hook function will get invoked on...

atexit handlers (and global/static variable destructors) are invoked by the thread that calls exit() (or returns from main). at_thread_exit handlers (and thread-specific variable destructors) should be invoked by the thread that called at_thread_exit, after it exits from its thread function.

cowwoc wrote:

One of my threads has the following logic:

{ at_thread_exit(myHook); while (!shutdownRequested) { // do stuff } }

myHook() { shutdownRequested = true; }

Following your scenario, doesn't this mean that the shutdown hook will never get executed? What will happen? Will exit() hang forever?

It will never get executed. The hook is executed AFTER the thread exits. exit() will not hang, it will just terminate the thread (and all other threads) as its very last step (after invoking the atexit handlers and global/static destructors).

cowwoc wrote:

Peter Dimov-5 wrote:

...

cowwoc wrote:

...

One of my threads has the following logic:

{ at_thread_exit(myHook); while (!shutdownRequested) { // do stuff } }

myHook() { shutdownRequested = true; }

Following your scenario, doesn't this mean that the shutdown hook will never get executed? What will happen? Will exit() hang forever?

It will never get executed. The hook is executed AFTER the thread exits.

So how do you propose I implement the use-case I mentioned?

This way: void threadproc() { while( !shutdownRequested ) { ... } } void signal_thread_to_exit_and_wait() { shutdownRequested = true; // join thread } int main() { // start thread atexit( signal_thread_to_exit_and_wait ); // ... } // exit( 0 ) happens here

cowwoc wrote:

PS: Is there a more reliable mechanism than atexit() that is guaranteed to support more than 32 hooks?

You could wrap the whole thing in a class, and use a static variable of that class so that its destructor will be called on exit. Something like (not compiled, not tested): class my_thread { private: boost::scoped_ptrboost::thread pt_; bool shutdown_request_; // more per-thread state, if needed void threadproc(); // as before public: my_thread(): shutdown_request_( false ) {} void start() { pt_.reset( new boost::thread( &my_thread::threadproc, this ) ); } ~my_thread() { if( pt_ ) { shutdown_request_ = true; pt_->join(); } } }; // ... static my_thread s_th; int main() { s_th.start(); // ... } // the destructor of s_th should be called here

Anthony Williams-4 wrote:

cowwoc writes:

...

Peter Dimov-5 wrote:

...

exit() will not hang, it will just terminate the thread (and all other threads) as its very last step (after invoking the atexit handlers and global/static destructors).

But what happens if one of the handlers is itself waiting for the thread to shut down?

If an atexit handler waits for a thread to shut down then it will block. If it is waiting for its own thread to shutdown then you have deadlock. That's easy to fix --- just set a flag to indicate to the atexit handler not to wait for this thread before you call exit.

...

Also, is at_thread_exit() implemented as an atexit() handler under the hood?

at_thread_exit is completely unrelated to atexit. It runs a function when the thread that called at_thread_exit returns from its thread function. For threads started with boost::thread this is done as part of the boost::thread internal thread management code. For threads started with platform-specific facilities such as CreateThread or pthread_create it is done using platform-specific hooks. Again, these do not interact with atexit handlers.

...

If not, how do you prevent it from killing the hook functions prematurely?

Calling exit() terminates all threads abruptly once the atexit handlers have run. Thread exit functions are not run for any threads. If threads are running at_thread_exit hooks they are terminated just as abruptly.

Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Anthony, That really clears things up. I would suggest that the documentation for at_thread_exit() mention these points. Thank you, Gili -- View this message in context: http://old.nabble.com/at_thread_exit%28%29-never-getting-called-tp26053513p2... Sent from the Boost - Users mailing list archive at Nabble.com.