I am not sure if this is possible at all in any other way but to write your own mini-debugger (using the debug API, you will get an event for every unhandled exception). Other than this, exceptions normally stay in the same thread, unless you do something explicit and special.

Why would you want to do this, anyway? It usually does not make much sense to catch exceptions in a different thread, unless the handler simply terminates the process. The actual purpose of exceptions is to handle some unexpected failure in a graceful way, i.e. backing off as much as needed so the program can still continue if possible at all.
I don't see how a handler thread knows enough about what is going on in some random other thread to be able of doing this.

Exceptions are stack unwinding mechanism. Stack is unwound either until it reaches the top, or until exception is handled.

Each thread has its own stack.

This makes threads and exceptions mutually exclusive. At least conceptually.


In practice it is sometimes beneficial to signal exceptions across threads. Perhaps to a logger or some coordinating mechanism. But at that point the original exception no longer serves its purpose. It is merely a log or a message, not an exception - the handling thread did not have an exception and cannot unwind a stack.

And if exception records a stack trace, the handling thread has no use for it - that stack no longer exists.


There are usually two separate issues here:
- Detecting abnormal condition in one of worker threads, possibly fatal, with the need to restart them.
- Having a centralized logging or notification system.

The solution to these is same. The exception must first be serialized in some way, maybe just a .what() will be enough. This message is then passed to handler thread using usual inter-thread communication. Handler thread does not deal with exceptions but simple user-defined objects.

Quote:Original post by Prune

the handler thread needs happens to be my main thread which does various other things and needs to be interrupted;

Thread interruption has been effectively abandoned. It's simply too problematic, even if well designed.

The boost's interruption is effectively just that - periodic checking for external events.

Quote:Things would work out much better if I can have an exception generated because then RAII would take care of a lot of things, including some of the recovery mechanisms.

But this doesn't make sense. If thread A throws an exception, B is completely independent. There is nothing to unwind in B since exception didn't happen there.

B may choose to throw a new exception to clean up its own stack upon learning that A has shutdown. In code, this looks something like this:

void thread_func() {  try {    // do the real work  } catch (std::exception & e) {    // unhandled exception    worker_exceptions.push.back(this.id(), e, ...);  }  // exit this thread normally}void main() {  while (running) {    // do something    if (!worker_exceptions.empty()) {      throw some_exception(foo, bar, baz);    }    // keep running  }}

No matter how it's implemented, this introduces asynchronous messaging. It also needs to handle all the associated cases, such as main not responding.

If worker thread attempted to interrupt main thread immediately - what would happen if during that time another thread interrupted main thread while it's cleaning up and exiting.

Quote:need to be handled immediately

Threads cannot do that. Unless running on a hard real-time OS, there is no guarantee main thread will ever wake up - it can remain suspended/unscheduled for arbitrary amount of time.

Quote:signal handlers

This is how interrupts work. But due to many issues they are also notoriously difficult to program, especially in user space. Making a tiny mistake inside a handler can bring down the system. Today's userspaces are highly isolated for this very reason.

The method presented above avoids the design issues present in interrupts while retaining the desired functionality. Anything beyond, such as any attempts to directly interact with code flow is simply not adequately supported by C or C++, especially in the automagic parts (destructors, RAII), which means results are unpredictable.

That code over at CodeProject is scary, if you ask me. First it uses SuspendThread, which is nasty stuff that should really never be used if you can help it at all (causes deadlocks in combination with wait functions), and then it tampers with the other thread's context. Which, meh... sure, will probably work, but... bleh. It's nasty.

If you do need to signal an exception, you can always just post a thread message. This is not the fastest thing in the world, but seeing how exceptions occur exceptionally, it will be fast enough. No tampering with half-documented internals that might change next week if you're unlucky or might not run on a different system.

But again, for most exceptions, handling them in another thread does not make an awful lot of sense. Logging or killing the process can be done easier and faster, without exceptions.
And pretty much everything else requires "knowledge" (this is what Antheus referred to with stack unwinding) that is not available to the other thread. Plus, the stack unwinding will be done anyway.
And lastly, in the (admittedly rare) cases where an exception handler can actually do something useful (something different than killing the process) only make sense in the same thread. For example, if you catch bad_alloc, you might want to try to free some memory that you can purge and try allocating again. The program could then (in the lucky case) continue as before, and nobody would ever know.
This wouldn't make sense when done in another thread.