This is the mail archive of the
mailing list for the glibc project.
[Bug nptl/20730] Need a way to tell pthread_cancel and pthread_exit don't do the forced unwind
- From: "baiyang at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 23 Oct 2016 11:21:27 +0000
- Subject: [Bug nptl/20730] Need a way to tell pthread_cancel and pthread_exit don't do the forced unwind
- Auto-submitted: auto-generated
- References: <email@example.com/bugzilla/>
--- Comment #2 from Bai Yang <baiyang at gmail dot com> ---
(In reply to Florian Weimer from comment #1)
> Could you provide more information why you need this?
> If we add such a function, it would be essentially broken, leaking resources
> and generally leaving the process in an undefined state, just like
> TerminateThread on Windows or java.lang.Thread#stop() on Java.
Yes, at least two reasons:
1. "kill a thread" is none involved with c++ exceptions, it disturb the normal
exception filtering, catching and processing job. I only see glibc do this,
others libc on linux and others OS seems all don't do that.
2. At least in some cases, We want cancel doing a dirty quick abnormal
termination for thread, we don't want it execute every distructor of the object
because it may be block few minutes, even few hours, e.g.: disconnect from a
remote mysql server which network cable has been cutting off.
Cancel is not a normal stop, we only use this api when the normal one (inform
the thread by set a flag or send a message to it, and wait itself stop) can't
work. In these situations, we don't trust the thread any more, and think the
thread could not finish the clean up within a reasonable duration.
So, cancel for thread is more like 'kill -9' for process in these use case. I
think that's why Windows, musl-libc, CLang libc, java and etc. provide
TerminteThread semantic API. glibc also need to provide one to deal with these
You are receiving this mail because:
You are on the CC list for the bug.