   pthreads and termination
  Hi.. If Iint main(int, char **){ pthread_t pt; pthread_create(&pt, 0, entry, 0); // wait a bit pthread_cancel(&pt);}void *entry(void *){ some_dynamic_object do(1234); for (;;) {  pthread_testcancel();  do_something(); }}Will, when the thread terminates at the 'pthread_testcancel()', do's destructor be called?   
  It should, since it goes out of scope... Try putting some debug output or something into the destructor and see for yourself :-).   ;  It might, on some platforms, but you can't rely on that behaviour across all conforming platforms.  Unfortunately the interactions between C++ features and POSIX Threads are not defined by POSIX and are likely to differ between platforms.  I believe there's some work underway to standardise on some behavior in a later POSIX release, but I don't know how far off that is.  Ideally you might want thread cancellations transformed into a C++ exception or something.When a thread is cancelled, the only destructor-style functionality you can rely on running are those things explicitly registered via pthread_cleanup_push().(For what it's worth, the dtor does run on a modern Linux system (Fedora rawhide), and does not run on an older OpenBSD installation I have.)In general, writing code that works properly in the face of thread cancellation is quite difficult, and it's usually best just to try and avoid cancellation altogether.  What were you planning to use cancellation for?  Perhaps someone can recommend another way to achieve what you want.   ;  Well here is the scenario.. I'm using 3 threads (reader / writer / watcher) which handle my UDP connections.. each of these can set a atom_int to an error code.. when the error code is set (i.e. != no_error) the threads will sleep for 2 seconds, check the error code, and if its clear again (no_error) continue on their tasks.. else they will sleep again.. The user of this class can access the error code and can pthread_cancel these threads.. reader allocates a 'buffer buf(1234);' at the start of its function.. so if reader gets cancelled buf will be in an unknown state (as you said I cannot rely on the destructor being called) Anyhow, these three threads are in a 'class net', and as I was typing this I just realized that there will be only 1 reader per class instance so I guess I could allocate the buffer in the class itself before all threads are started.. Heh, I guess I just solved my own problem.. Its a wonder what typing out a description of what you are trying to do can solve..  ;  Correct me if I'm wrong, but it is generally not a good idea to cancel a thread. Politely asking the thread to come to an end via some sort of notification and then acting on that request from within said thread should be preferred over just pulling away the ground from underneath the thread's feet.   ;  Yes, it will.Cancelling the thread doesn't forcibly terminate it, so it will continue with whatever stack behaviour as it exits the thread main function.You should probably call pthread_join after pthread_cancel to wait for the thread to finish. Otherwise, main() might exit and the process quit before the destructor was called (which it would be, provided yuo did pthread_join)Mark   ;Quote:Original post by markrYes, it will.Sorry, you're late to the party, and seem to have forgotten that it was fancy dress. ;-)Quote:Original post by markrCancelling the thread doesn't forcibly terminate it, so it will continue with whatever stack behaviour as it exits the thread main function.The only behaviour that POSIX requires for thread cancellation is:Quote:The pthread_cancel() function shall request that thread be canceled. The target thread's cancelability state and type determines when the cancellation takes effect. When the cancellation is acted on, the cancellation cleanup handlers for thread shall be called. When the last cancellation cleanup handler returns, the thread-specific data destructor functions shall be called for thread. When the last destructor function returns, thread shall be terminated.-- http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cancel.htmlAs Red Ant said, it's not a good idea to cancel threads, particularly as a way to "nicely" ask another thread to terminate.  Why not?  Because getting cancel right is extremely difficult.  Cancellation is an asynchronous termination request, and will only be ignored if the thread is explicitly not cancellable, or if the thread is inside a non-cancellable operation.  Cancellation behaves very similarly to UNIX signals (which are already notoriously difficult to deal with).Per the behaviour quoted above, you can either have a given thread cancellable or not.  If a thread is cancelled, it will run any registered cancellation handlers, then run any TSD destructors (which are registered via pthread_key_create()).  Within this behaviour, you need to arrange for any and all cleanup to be performed (this includes bringing any locked data into a consistent state and then releasing the appropriate locks, for example).;Quote:Original post by bradbobakI'm using 3 threads (reader / writer / watcher) which handle my UDP connections.. each of these can set a atom_int to an error code.. when the error code is set (i.e. != no_error) the threads will sleep for 2 seconds, check the error code, and if its clear again (no_error) continue on their tasks.. else they will sleep again.. The user of this class can access the error code and can pthread_cancel these threads.. reader allocates a 'buffer buf(1234);' at the start of its function.. so if reader gets cancelled buf will be in an unknown state (as you said I cannot rely on the destructor being called)Are the readers and writers using blocking or non-blocking I/O?  If you're using non-blocking I/O, I would suggest using a 'quit' flag for each thread.  Each time around the loop the thread can check the flag and clean up and exit if appropriate.  You'd need to use a timeout in your event polling mechanism (e.g. select()) to ensure the flag was checked in a timely manner.It's much tricker if you're using blocking I/O... if you can't move to using non-blocking I/O, thread cancellation does become one option, because blocking I/O calls act as thread cancellation points, and it is one of the few ways to break the blocked action.  If you take this route, read up on pthread_setcancelstate() and pthread_setcanceltype(), and make sure that you only have cancellation enabled during points in the code when you are sure it is safe to received a cancellation.   ;  Nah, I'm using non-blocking io.. I'll switch over to the flag idea.. thanks   