Answer the question
In order to leave comments, you need to log in
Will it help to move the work with the crashing library to a separate thread from the crash of the entire application?
Greetings!
In general, there is either - it crashes from time to time for its own reasons, it is impossible to influence the developer.
I want to try to put all the work with it into a separate thread...
So, how can I make sure that only a separate thread crashes without affecting the application as a whole? Cross- platform...
PS It is in another thread, not a process.
Answer the question
In order to leave comments, you need to log in
In short, most likely not. Cross-platform - even more doubtful.
How exactly is it painted? As I understand it, this is not a C++ exception thrown, but something like a memory corruption (although there may be something nasty like if(fail){exit(-1);} in the lib itself, which is already problematic to work with). In theory, it is possible to process this for each platform. If right away - how can this be implemented for Windows:
In fact, we take out work with either in a separate thread. When it does something bad (like trying to read freed memory), a SEH exception will be thrown, for which we can register a handler (using a vectored exception handler in msdn). In the handler, it would be possible to check that the exception was thrown exactly from the thread of this lib, and if this is really the case, just bang this thread. But even if this extremely bad method works - it either grabs some resources and there is no guarantee that it will correctly release them when the thread falls (and that the application will generally remain in a consistent state - who knows why it falls - maybe there at all half of the memory before this garbage is overwritten). In short, the threading solution is a potentially unstable operation for the entire application.
To isolate memory and use resources, there are just processes, no matter how much you would like to get away from them :)
So a solution with a separate process that will isolate all the sores of either and prevent them from spreading to the entire application is still the safest.
You can fork yourself with the necessary parameters and load only the lib handler itself in the background without everything else and get the result of processing the lib through the pipe.
Fall off - not a question: again fork.
(this is the first thing that came to mind)
Also, you can move the loader to a separate dynamic lib, so as not to drag a lot into the RAM.
There already - according to the situation, you need to die ...
The topic goes beyond pure C++. The author tell me if you have Windows or Linux.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question