This is the mail archive of the 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/20730] Need a way to tell pthread_cancel and pthread_exit don't do the forced unwind

--- 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
dirty works.

You are receiving this mail because:
You are on the CC list for the bug.

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