This is the mail archive of the glibc-bugs@sourceware.org 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


https://sourceware.org/bugzilla/show_bug.cgi?id=20730

--- Comment #4 from Bai Yang <baiyang at gmail dot com> ---
(In reply to Florian Weimer from comment #3)
> (In reply to Bai Yang from comment #2)
> > (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.
> 
> Something like it is required that you can write cancellation handlers using
> the C++ unwind mechanism.
> 
> Adding the function you request would break that.

Assume we are using a 3rd party library, which has a TThread clase like:

class TThread 
{
    // ...
    virtual int Entry(void) = 0; // Thread Entry
    virtual void OnUncaughtException(void) throw(); // deal exceptions throw by
Entry
}

You can imaging there MUST something like this in the library:
try 
{
    Entry()
}
catch (...)
{
    OnUncaughtException();
}
// ...

It's a common pattern to prevent the exception throw across the thread
boundary. And work well with all OS libraries except glibc, because all other
systems "libc" (Windows "kernel32", linux musl-libc, linux CLong libc, Solaris,
HP-UX, AIX, and etc.) both agree that kill a thread IS NOTING ABOUT A C++
EXCEPTION!

So, this "unique feature" of glibc caused following problems:
1. The 3rd party code may be very difficult to change.
2. A lot of existing codes rely on the 3rd party lib that buy in this pattern
need to change, It's huge work.

So, at least give us a option to turn off this glibc "unique feature".

> 
> > 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. 
> 
> This is really a fringe case.  Most applications would not be able to cope
> with the resource leaks (memory and file descriptors).  If resource
> consumption does not matter, you could just not cancel the thread at all.

We can cope it by something like "modeler isolation", or by other methods. Why
Windows, Java, musl-libc, CLong libc and a lot of others provide this function?
They all wrong, only you are right?

Even if only you know "they all wrong and the world is wrong", you still need
to compliance the wrong world, to make other existing codes not broken on your
lib. 

You can implement an unconventional default "right action", but at least
"compliance the wrong world" through some optional settings.

Of course we can solve this issue by use longjmp, but I still think glibc NEED
to give us a way to do the "conventional action".

thanks

-- 
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]