Could main thread catch exception threw by other thread
-
@jonb said in Could main thread catch exception threw by other thread:
Of course whether that happening upsets your other threads I can't say.
Unhandled exceptions (in the thread) propagate back to the kernel's exception handler, whose code is going to
abort()the whole process. So yeah, the other threads are also mildly disturbed.@qingshui-kong said in Could main thread catch exception threw by other thread:
But I can't make sure there is no coding issue total.
No one can. Airplanes have fallen for less serious offences. Be clean and write clean code is a good rule of thumb.
If there is no solution, maybe I should try my best to catch all the exceptions in the thread.
You could, but I'm not entirely convinced. Say your code throws an alloc exception, you're going to catch that? Doubtful, as the exception needs memory itself. What are you exactly trying to handle?
@kshegunov @JonB
Thanks a lot!You could, but I'm not entirely convinced. Say your code throws an alloc exception, you're going to catch that? Doubtful, as the exception needs memory itself. What are you exactly trying to handle?I mean I should try to avoid as more error as I can. And try to catch the exception that I can catch.
So could you give me some suggestions? What should I do in that case? Just leave the application crash?
-
@kshegunov @JonB
Thanks a lot!You could, but I'm not entirely convinced. Say your code throws an alloc exception, you're going to catch that? Doubtful, as the exception needs memory itself. What are you exactly trying to handle?I mean I should try to avoid as more error as I can. And try to catch the exception that I can catch.
So could you give me some suggestions? What should I do in that case? Just leave the application crash?
@qingshui-kong said in Could main thread catch exception threw by other thread:
So could you give me some suggestions? What should I do in that case? Just leave the application crash?
If you don't know how to handle the exception, then yes, let it crash. Otherwise you are leaving the application in an unknown state that your don't understand, which could lead to all sorts of security issues or data corruption bugs that are even worse than crashing.
Writing the code to correctly handle as many errors and exceptions as possible is part of the job of being a programmer. There's no way to cheat.
-
@jonb said in Could main thread catch exception threw by other thread:
Of course whether that happening upsets your other threads I can't say.
Unhandled exceptions (in the thread) propagate back to the kernel's exception handler, whose code is going to
abort()the whole process. So yeah, the other threads are also mildly disturbed.@qingshui-kong said in Could main thread catch exception threw by other thread:
But I can't make sure there is no coding issue total.
No one can. Airplanes have fallen for less serious offences. Be clean and write clean code is a good rule of thumb.
If there is no solution, maybe I should try my best to catch all the exceptions in the thread.
You could, but I'm not entirely convinced. Say your code throws an alloc exception, you're going to catch that? Doubtful, as the exception needs memory itself. What are you exactly trying to handle?
Unhandled exceptions (in the thread) propagate back to the kernel's exception handler, whose code is going to abort() the whole process. So yeah, the other threads are also mildly disturbed.
So to be clear, you are saying unhandled exceptions in (any) thread abort the whole host process, is that right? I thought they only cause termination of the thread they arise in. I wonder what it is that has to cause this behaviour, could it not have been isolated to the thread?
-
Unhandled exceptions (in the thread) propagate back to the kernel's exception handler, whose code is going to abort() the whole process. So yeah, the other threads are also mildly disturbed.
So to be clear, you are saying unhandled exceptions in (any) thread abort the whole host process, is that right? I thought they only cause termination of the thread they arise in. I wonder what it is that has to cause this behaviour, could it not have been isolated to the thread?
@jonb said in Could main thread catch exception threw by other thread:
So to be clear, you are saying unhandled exceptions in (any) thread abort the whole host process, is that right?
Yes.
I thought they only cause termination of the thread they arise in.
Nope. After they unwind your thread's stack they are caught by the ever-present global exception handler in the kernel, which in turn calls
abort()on your process.I wonder what it is that has to cause this behaviour, could it not have been isolated to the thread?
Consistency. Threads share the same address space, unlike processes, meaning that if your thread has locked a mutex for example, terminating only that thread means the mutex is going to remain locked forever for the lifetime of the process.
Now imagine another thread (main for example) has acquired a global primitive (say a semaphore) and is waiting on that aforementioned mutex for whatever trivial reason. Suddenly you've hanged the process and at the same time prevented any other possible instance of that process. That process became a super-zombie.
Usually you can catch the relevant signal to clean up global primitives, but now you can't because your process is alive it's not being terminated, yet it can't be reached by any means, it just hangs there waiting for a non-existing thread. The only thing that can be done is to have the kernel forcefully terminate it.
See the irony? In such a case it's best the kernel abort the process immediately, instead of trying to be clever and kill only the thread. Similar inference can be made for a thread-safe queue, where if the producer(s) crash the consumers wait for no reason. What's their purpose then? What would be the purpose of the process?Read and abide by the Qt Code of Conduct
-
@jonb said in Could main thread catch exception threw by other thread:
So to be clear, you are saying unhandled exceptions in (any) thread abort the whole host process, is that right?
Yes.
I thought they only cause termination of the thread they arise in.
Nope. After they unwind your thread's stack they are caught by the ever-present global exception handler in the kernel, which in turn calls
abort()on your process.I wonder what it is that has to cause this behaviour, could it not have been isolated to the thread?
Consistency. Threads share the same address space, unlike processes, meaning that if your thread has locked a mutex for example, terminating only that thread means the mutex is going to remain locked forever for the lifetime of the process.
Now imagine another thread (main for example) has acquired a global primitive (say a semaphore) and is waiting on that aforementioned mutex for whatever trivial reason. Suddenly you've hanged the process and at the same time prevented any other possible instance of that process. That process became a super-zombie.
Usually you can catch the relevant signal to clean up global primitives, but now you can't because your process is alive it's not being terminated, yet it can't be reached by any means, it just hangs there waiting for a non-existing thread. The only thing that can be done is to have the kernel forcefully terminate it.
See the irony? In such a case it's best the kernel abort the process immediately, instead of trying to be clever and kill only the thread. Similar inference can be made for a thread-safe queue, where if the producer(s) crash the consumers wait for no reason. What's their purpose then? What would be the purpose of the process?@kshegunov
Thanks. I understand all of that, but it's not the behaviour I was expecting.When, say, a process opens a file, and holds a lock on it, if the process is forcibly terminated, the kernel releases the locks/closes the files on its behalf. Same with pipes and other resources. Anything else waiting on those sees them released with an
EINTRor whatever.So of course I understand about mutexes, semaphores or waits on other threads. I expected those to get terminated by the kernel if the thread aborts/terminates, while allowing other threads to continue, receiving appropriate results for any calls in progress which shared something with the dying thread.
But apparently not!
-
@kshegunov
Thanks. I understand all of that, but it's not the behaviour I was expecting.When, say, a process opens a file, and holds a lock on it, if the process is forcibly terminated, the kernel releases the locks/closes the files on its behalf. Same with pipes and other resources. Anything else waiting on those sees them released with an
EINTRor whatever.So of course I understand about mutexes, semaphores or waits on other threads. I expected those to get terminated by the kernel if the thread aborts/terminates, while allowing other threads to continue, receiving appropriate results for any calls in progress which shared something with the dying thread.
But apparently not!
@jonb said in Could main thread catch exception threw by other thread:
So of course I understand about mutexes, semaphores or waits on other threads. I expected those to get terminated by the kernel if the thread aborts/terminates, while allowing other threads to continue, receiving appropriate results for any calls in progress which shared something with the dying thread.
But apparently not!
The kernel only cleans up when the process ends. Killing a thread does not stop the process itself, so the kernel won't do anything here.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@jonb said in Could main thread catch exception threw by other thread:
So of course I understand about mutexes, semaphores or waits on other threads. I expected those to get terminated by the kernel if the thread aborts/terminates, while allowing other threads to continue, receiving appropriate results for any calls in progress which shared something with the dying thread.
But apparently not!
The kernel only cleans up when the process ends. Killing a thread does not stop the process itself, so the kernel won't do anything here.
@jksh
And my point here is precisely that I expected the kernel would clean up thread resources on thread exit, but apparently it does not. I'm pretty sure/thought at least certain thread resources are released/cleaned on thread termination (but perhaps not when it's an exception) without having to wait for process termination, but there you are. -
@jksh
And my point here is precisely that I expected the kernel would clean up thread resources on thread exit, but apparently it does not. I'm pretty sure/thought at least certain thread resources are released/cleaned on thread termination (but perhaps not when it's an exception) without having to wait for process termination, but there you are.@jonb said in Could main thread catch exception threw by other thread:
thread resources
What are thread resources? The point is that you have no such thing, you have process resources that are shared between the threads.
Read and abide by the Qt Code of Conduct
-
@jonb said in Could main thread catch exception threw by other thread:
thread resources
What are thread resources? The point is that you have no such thing, you have process resources that are shared between the threads.
@kshegunov
That is indeed the point! I had thought that there are thread resources, like say a semaphore having some support for recognising when threads attach/wait on it, but now I'm thinking this may not be the case, as you say. -
@qingshui-kong said in Could main thread catch exception threw by other thread:
So could you give me some suggestions? What should I do in that case? Just leave the application crash?
If you don't know how to handle the exception, then yes, let it crash. Otherwise you are leaving the application in an unknown state that your don't understand, which could lead to all sorts of security issues or data corruption bugs that are even worse than crashing.
Writing the code to correctly handle as many errors and exceptions as possible is part of the job of being a programmer. There's no way to cheat.
@wrosecrans
Thanks a lot for your answer.@JonB @kshegunov @JKSH
And thanks for your discussion. I learnt a lot from that.
