This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/415] pthread_cancel does not unwind stack when thread is cancelled inside signal handler


------- Additional Comments From yufeng_xiong at ltx dot com  2004-10-01 13:12 -------
(In reply to comment #2)
> What you want is completely bogus, this never can work anywhere reliably.  
Which
> is why it is not required in POSIX.
> The only thing which might have to be done is to disable cancellation while 
the
> signal handler is executed.  And even that might not be required.
> If your code depends on cancellation in signal handlers, you better rewrite 
it.

Hi Ulrich,

Thanks very much for replying to my report.

I have some different opinion, the truth is that POSIX thread standard does not 
talk about objects at all, it is a C-based standard, however, the MT-
programming community tend to agree pthread_cancel and pthread_exit should 
cause a thread stack unwind and all stack based objects be destructed, and your 
NPTL is specifically designed to achieve this goal (solve the early GNU 
compiler/LinuxThread problem), I would expect this to work no matter where/how 
it is called. This works perfectly fine using SUN's Workshop compiler (6.2) on 
Solaris system.

I totally agree this is not a natural thing to do, but extreme cases require 
extreme solution. In my case, it is required that a running thread is able to 
be terminated no matter what, we normally use a flag to achieve this, but that 
can not be 100% reliable given there are third party code and customer code, on 
second stage we try pthread_cancel (with the default deferred cancellation 
type), and this is also not 100% reliable since the thread may not hit a 
cancellation point for a long time, so we try this third stage, using a signal 
to break the thread and make it cancelled inside the signal handler, we can 
also make the thread call pthread_exit inside the signal handler, but the 
standard says it's not safe to do so, and also pthread_exit has the same thread 
unwind problem as pthread_cancel inside signal handler on Linux. Note that we 
don't want to async cancellation because we believe it is not as safe as the 
deferred cancellation.

Note that POSIX standard does not say a thread can not be cancelled inside a 
signal handler, nor does it say it is unsafe to cancel a thread when it is 
inside it's signal handler, that's why I think it should work just as a normal 
cancellation.

On the other hand, is there a technical reason that it can not be done at all? 
or it's just you feel so strongly object to this type of programming make you 
not willing to do it? My understanding is that pthread_cancel is usually also 
implemented as sending a signal (SIGCANCEL), which may be trapped at the kernel 
lever and not get into user thread (like a normal signal does), but it does 
have some similarity with a regular signal behavior, so why a normal 
cancellation works fine, but once the thread goes into it's signal handler, 
then it can be cancelled but thread stack can not be unwind? It sounds to me it 
is doable (Note I'm not very falimiar with Linux, and I don't know anything 
about Linux Kernel and NPTL implementation at all, so those are just my 
assumptions).

Thanks very much for communicating with me.

Best Regards,

Yufeng


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=415

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]