pthread_cancel c++

chenzhanyiczy

1. class Info
   
2. {
   
3. public:
   
4.     ~Info()
   
5.     {
   
6.         printf("~Info()\n");        //-----1
   
7.     }
   
8. };
   
9. 
   
10. void thread_cleanup(void* arg)
    
11. {
    
12.                 printf("thread id=%lu cleanup\n",pthread_self());            //-----2
    
13. 
    
14. }
    
15. 
    
16. void*  func(void  *arg)
    
17. {
    
18.      int tick;
    
19. 
    
20.     pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
    
21.     pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,   NULL);
    
22.    
    
23.     Info info;
    
24.     pthread_cleanup_push(thread_cleanup,NULL);
    
25. 
    
26.     while(1)
    
27.       {
    
28.            tick++;
    
29.            sleep(1);                //-----3
    
30.   }
    
31. 
    
32.     pthread_cleanup_pop(0);
    
33.     return NULL;
    
34. }
    
35. 
    
36. int main()
    
37. {
    
38.     pthread_t thread[1];
    
39. 
    
40.     pthread_create(&thread[0],   &attr,   func,   NULL) ;
    
41. 
    
42.     sleep(4);
    
43. 
    
44.     if(!pthread_cancel(thrd[0]))
    
45.       printf("cancel ok\n");
    
46. 
    
47.     sleep(1000);
    
48. }

复制代码

很简单的一段测试线程取消的代码。

首先，不管是否3有无，线程都可以被取消退出。
再者：
如果把3去掉,那么1和2都不对打印
如果保留3,那么1和2都打印
也就是说，加了个sleep（不单单是sleep，凡是系统调用都可以），就能析构栈上的局部变量和调用cleanup函数；不加，则不会。

PS：
0、pthread_cancel是通过发送信号实现的，信号值是32。具体可看glibc pthread_cancel.c源码
1、查看过kernel 信号部分源码，没发现阻塞系统调用和死循环运行，两者在收到信号后，有什么不同的处理情况。
2、从glibc相关源码，可以看出，局部对象的析构和cleanup情况都是通过_Unwind_ForcedUnwind()实现的,这个具体到c++，就是在libsupc++/eh_personality.cc实现的.
   当然如果是c的话，是不同的，通过setlongjmp实现

想来想去，应该是跟c++栈unwind有关，但想不明白为啥系统调用对栈unwind有什么影响？

myworkstation

因为加上sleep线程就成为 Cancel-Safe的。而使用Asynchronous cancellation模式时Cancel-Safe的才是Asynchronous-Cancel-Safety的。当取消的类型为PTHREAD_CANCEL_ASYNCHRONOUS时，新到的或未决的取消请求可能在任意时刻起作用.只有从一个线程中调用cancel-safe的函数时这个线程才是异步可取消的。不然不能保证cleanup handler被调用。Ｃ＋＋的构造，析构函数都不是Cancel-Safe的所以也不能保证被执行(这个取决于实现LLVM和GCC的行为不同）。大部分库函数都不是async-cancel-safe的。linux相关文档没有明确说明哪些函数是async-cancel-safe的。posix标准只规定了三个async-cancel-safe的函数：pthread_cancel(), pthread_setcancelstate(), and pthread_setcanceltype()。




man

When cancelability is enabled and the cancelability type is PTHREAD_CANCEL_ASYNCHRONOUS, new or pending cancellation requests may be acted upon at any time。only functions that are cancel-safe may be called from a thread that is asynchronously cancelable.


POSIX :

Async-Cancel Safety
A function is said to be async-cancel-safe if it is written in such a way that entering the function with asynchronous cancelability enabled will not cause any invariants to be violated, even if a cancellation request is delivered at any arbitrary instruction. Functions that are async-cancel-safe are often written in such a way that they need to acquire no resources for their operation and the visible variables that they may write are strictly limited.
Any routine that gets a resource as a side-effect cannot be made async-cancel-safe (for example, malloc()). If such a routine were called with asynchronous cancelability enabled, it might acquire the resource successfully, but as it was returning to the client, it could act on a cancellation request. In such a case, the application would have no way of knowing whether the resource was acquired or not.
Indeed, because many interesting routines cannot be made async-cancel-safe, most library routines in general are not async-cancel-safe. Every library routine should specify whether or not it is async-cancel safe so that programmers know which routines can be called from code that is asynchronously cancelable

linux_c_py_php

很奇怪, 只要被取消应该都执行的, 除非cancel在push之前, 但你加了sleep的.

chenzhanyiczy

回复 2# myworkstation


    不是这个原因，把上面的换成用gcc编译，也就是纯c的话，无论有没有sleep()都是正常的。

myworkstation

回复 4# chenzhanyiczy


    我之前写了一些文档规定的东东，实际上posix明确规定了c如果处理这种情况，但对C++没作规定，g++使用异常来实现stack unwinding。如果在你写的那个while循环中没有任何其它调用，只有简单语句赋值的话将不会导致C++的CRT产生异常，线程被直接终止，这应该是CRT的实现不完善造成的，而且C++在这方面也没什么可移植性，每个平台可能都不一样（MACOS,AIX等)。无论是C还是C++对pthread_cancel的调用都会导至系统发出一个SIGRTMIN信号来终止线程，在C++的情况下可能在循环中含有检查信号的调用时才会正常生成异常，从而让线程肯恢复执行始可以做stack unwinding也能让clean handler执行。而c的crt好像没这个特殊要求。

chenzhanyiczy

回复 5# myworkstation


    不是说不对，但这样的猜测要有依据(标准或者代码证实等)

    之前说过，检查信号处理过程在有没有sleep都是一样的，这点可以确定(具体可以看看kernel源码)

   现在就是想找到为什么没加sleep就不会stack unwind的原因，具体到代码。

   gnu c++的stack unwind处理应该放在libsupc++/eh_personality.cc里
  
PS:
1、不用再讨论c的情况了,因为c方面完全没有问题，实现原理都在glibc里，可以看看

myworkstation

回复 6# chenzhanyiczy


    现有的标准对C++在这方面的行为根本没什么具体的规定，所以从标准上来讲对C++来说就是没标准，完全看具体的平台实现。至于GCC ,我觉得这个地方应该找到你感兴趣的东西。代码太多我就不去看了。你有兴趣看的话可以把研究的结果回在贴子里， http://thread.gmane.org/gmane.comp.gcc.help/41456