Does the signal()
function overwrite other signal calls a process might have set up? I.e. if a SIGINT
handler has been setup by a process, and a DLL calls signal(SIGINT,xxx)
to handle its own termination code, does the original SIGINT
handler get disabled?
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- How to know full paths to DLL's from .csproj f
- thread_local variables initialization
相关文章
- vs2017wpf项目引用dll的路径不正确的问题
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
- What exactly do pointers store? (C++)
- Converting glm::lookat matrix to quaternion and ba
This is not a "literal" answer to your question, but a recommendation: You shouldn't do this in a DLL.
It is unexpected and often annoying for the application that uses the DLL. A DLL should (normally) be "passive" and only provide functions for the application to call.
So rather provide a public function from your DLL that applications are required to call e.g.
MyDllCleanup()
. Then let the application decide how it calls that function (via a signal handler or other). BTW, the same goes for initialization: rather than relying onDllMain
(or_init
/_fini
withlibdl
on UNIX) provide explicit functions for applications to call.The
signal()
call:The new handler will be called instead of the old one. If you want to chain them, you need to do something like:
If interrupts were being ignored, this keeps them ignored. If interrupts were being handled by a user-defined interrupt handler, then this calls your signal handling code and the original signal handling code.
Note that the advice from Christian.K about not handling signals in a DLL (shared library) is also relevant and valid. The description above assumes you decide to ignore that advice.