This is the mail archive of the mailing list for the libstdc++ 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]

Re: terminate handler global or per thread?

On Fri, Aug 21, 2009 at 3:25 PM, Ian Lance Taylor<> wrote:
> Mike Harrold <> writes:
>> On Fri, Aug 21, 2009 at 5:29 PM, Ian Lance Taylor <> wrote:
>>> The terminate handler is a normal global variable. ?It is not thread
>>> local.
>> Doesn't this introduce all kinds of issues regarding thread safety?!?
> If you want to have different terminate handlers in different threads,
> then, yes, it certainly does. ?But that seems like a fairly unusual use
> case to me.
> Ian

No, it's a problem even if you want the same terminate handler in all threads.

Here's the way I use terminate handlers:

I use exceptions that collect stack traces. When my exception causes
termination, I print out the stack trace using a custom terminate
handler (why doesn't std::exception do this out of the box?!). In
order to make sure that handler is always registered, I register it
the first time the exception constructor is called. Because of this if
terminate handler is not thread local, I need explicit synchronization
over my global "is my terminate handler already set" flag.

I think you are thinking along the lines of setting the terminate
handler in the main routine before all other other threads are
spawned. However, that's not ideal, since it requires some kind of
explicit initialization function for every library you use that
registers a terminate handler, instead of just setting it lazily,
which is easiest for the user.

I know the draft C++1x standard introduces thread local variables...
does anyone know if the terminate handler is supposed to be thread
local now? If so I guess the change would break some existing threaded


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