In case the application already set a SIGDEBUG handler, let that one handle any potential SIGDEBUG_NOMLOCK events and keep our handler (xeno_handle_mlock_alert) out of the loop. This helps in scenarios where skin libraries are loaded belatedly via dlopen.
Signed-off-by: Jan Kiszka <[email protected]> --- Anything that speaks against this? We ran into that issue with a large application, and that can be one way to solve but should even make sense in general. include/asm-generic/bits/bind.h | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/asm-generic/bits/bind.h b/include/asm-generic/bits/bind.h index 269be95..f39c853 100644 --- a/include/asm-generic/bits/bind.h +++ b/include/asm-generic/bits/bind.h @@ -23,6 +23,11 @@ xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module) exit(EXIT_FAILURE); } + /* do not overwrite an already installed SIGDEBUG handler */ + sigaction(SIGXCPU, NULL, &sa); + if (sa.sa_handler != SIG_DFL) + return muxid; + sa.sa_sigaction = xeno_handle_mlock_alert; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_SIGINFO; -- 1.7.3.4 _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
