Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. Jan, do you agree? The main argument is that people may use third-party libraries such as, say, libreadline or libqt which intercept the SIGWINCH signal, and that we do not want to recompile these libraries to run with Xenomai. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. Jan, do you agree? The main argument is that people may use third-party libraries such as, say, libreadline or libqt which intercept the SIGWINCH signal, and that we do not want to recompile these libraries to run with Xenomai. Yes, I'm fine with the current approach + doc + xeno_sigwinch_handler. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. Jan, do you agree? The main argument is that people may use third-party libraries such as, say, libreadline or libqt which intercept the SIGWINCH signal, and that we do not want to recompile these libraries to run with Xenomai. Yes, I'm fine with the current approach + doc + xeno_sigwinch_handler. Ok. Since I am going to paste the doc in four different places, I'd better get it right from the beginning. Here is my prose: * @note: When creating or shadowing a Xenomai thread in user-space, for the * first time, Xenomai installs a handler for the SIGWINCH signal. If you had * installed a handler before that, it will be automatically called by Xenomai * for SIGWINCH signals that it has not sent. * * If, however, you install a signal handler for SIGWINCH after creating * or shadowing the first Xenomai thread, you have to explicitely call the * function xeno_sigwinch_handler at the beginning of your signal handler, * using its return to know if the signal was in fact an internal signal of * Xenomai (in which case it returns 1), or if you should handle the signal (in * which case it returns 0). xeno_sigwinch_handler prototype is: * * bint xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt);/b * * Which means that you should register your handler with sigaction, using the * SA_SIGINFO flag, and pass all the arguments you received to * xeno_sigwinch_handler. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. Jan, do you agree? The main argument is that people may use third-party libraries such as, say, libreadline or libqt which intercept the SIGWINCH signal, and that we do not want to recompile these libraries to run with Xenomai. Yes, I'm fine with the current approach + doc + xeno_sigwinch_handler. Ok. Since I am going to paste the doc in four different places, I'd better get it right from the beginning. Here is my prose: * @note: When creating or shadowing a Xenomai thread in user-space, for the * first time, Xenomai installs a handler for the SIGWINCH signal. If you had * installed a handler before that, it will be automatically called by Xenomai * for SIGWINCH signals that it has not sent. * * If, however, you install a signal handler for SIGWINCH after creating * or shadowing the first Xenomai thread, you have to explicitely call the explicitly (I regularly mistype this as well...) * function xeno_sigwinch_handler at the beginning of your signal handler, * using its return to know if the signal was in fact an internal signal of * Xenomai (in which case it returns 1), or if you should handle the signal (in * which case it returns 0). xeno_sigwinch_handler prototype is: * * bint xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt);/b * * Which means that you should register your handler with sigaction, using the * SA_SIGINFO flag, and pass all the arguments you received to * xeno_sigwinch_handler. Sounds good to me. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote:
Hi,
here is a patch which implements the idea discussed previously of
re-using SIGWINCH to trigger priority changes in user-space. There is
only one patch, but the files should have been put in a logical order
to make review easier.
Thanks for providing this. Find a few comments below, primarily
targeting the (not new) signal hooking strategy.
Index: include/nucleus/thread.h
===
--- include/nucleus/thread.h (revision 4218)
+++ include/nucleus/thread.h (working copy)
@@ -116,6 +116,7 @@
#define XNROBBED 0x0020 /** Robbed from resource ownership */
#define XNATOMIC 0x0040 /** In atomic switch from secondary to primary
mode */
#define XNAFFSET 0x0080 /** CPU affinity changed from primary mode */
+#define XNPRIOSET 0x0100 /** Priority changed from primary mode */
/* These information flags are available to the real-time interfaces */
#define XNTHREAD_INFO_SPARE0 0x1000
Index: include/asm-generic/syscall.h
===
--- include/asm-generic/syscall.h (revision 4218)
+++ include/asm-generic/syscall.h (working copy)
@@ -59,7 +59,12 @@ typedef struct xnsysinfo {
unsigned long tickval; /* Tick duration (ns) */
} xnsysinfo_t;
-#define SIGHARDEN SIGWINCH
+#define SIGSHADOW SIGWINCH
+#define SIGSHADOW_ACTION_HARDEN 1
+#define SIGSHADOW_ACTION_RENICE 2
+#define sigshadow_action(code) ((code) 0xff)
+#define sigshadow_prio(code) (((code) 8) 0xff)
+#define sigshadow_int(action, prio) ((action) | ((prio) 8))
#ifdef __KERNEL__
Index: include/nucleus/shadow.h
===
--- include/nucleus/shadow.h (revision 4218)
+++ include/nucleus/shadow.h (working copy)
@@ -98,6 +98,7 @@ void xnshadow_reset_shield(void);
void xnshadow_send_sig(struct xnthread *thread,
int sig,
+int arg,
int specific);
void xnshadow_rpi_check(void);
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 4218)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -115,6 +115,14 @@ do { \
switch_lock_owner[task_cpu(t)] = t; \
} while(0)
+#define xnshadow_sig_mux(sig, arg) ((sig) | (arg 8))
+#define xnshadow_sig_demux(muxed, sig, arg) \
+ do { \
+ int _muxed = (muxed);\
+ (sig) = _muxed 0xff; \
+ (arg) = _muxed 8; \
+ } while (0)
+
static struct task_struct *switch_lock_owner[XNARCH_NR_CPUS];
static int nucleus_muxid = -1;
@@ -879,7 +887,7 @@ static void xnshadow_dereference_skin(un
static void lostage_handler(void *cookie)
{
- int cpu = smp_processor_id(), reqnum, sig;
+ int cpu = smp_processor_id(), reqnum, sig, arg;
struct __lostagerq *rq = lostagerq[cpu];
while ((reqnum = rq-out) != rq-in) {
@@ -927,8 +935,16 @@ static void lostage_handler(void *cookie
case LO_SIGTHR_REQ:
- sig = rq-req[reqnum].arg;
- send_sig(sig, p, 1);
+ xnshadow_sig_demux(rq-req[reqnum].arg, sig, arg);
+ if (sig == SIGSHADOW) {
+ siginfo_t si;
+ memset(si, '\0', sizeof(si));
+ si.si_signo = sig;
+ si.si_code = SI_QUEUE;
+ si.si_int = arg;
+ send_sig_info(sig, si, p);
+ } else
+ send_sig(sig, p, 1);
break;
case LO_SIGGRP_REQ:
@@ -1235,6 +1251,13 @@ void xnshadow_relax(int notify)
/* Help debugging spurious relaxes. */
send_sig(SIGXCPU, current, 1);
+ if (xnthread_test_info(thread, XNPRIOSET)) {
+ xnthread_clear_info(thread, XNPRIOSET);
+ xnshadow_send_sig(thread, SIGSHADOW,
+ sigshadow_int(SIGSHADOW_ACTION_RENICE, prio),
+ 1);
+ }
+
#ifdef CONFIG_SMP
/* If the shadow thread changed its CPU affinity while in
primary mode, reset the CPU affinity of its Linux
@@ -1485,13 +1508,13 @@ void xnshadow_start(xnthread_t *thread)
void xnshadow_renice(xnthread_t *thread)
{
/* Called with nklock locked, Xenomai interrupts off. */
I think this comment line should be pushed in front of the function at
this chance.
- struct task_struct *p = xnthread_archtcb(thread)-user_task;
-
/* We need to bound the priority values in the [1..MAX_RT_PRIO-1]
range, since the core pod's priority scale is a superset of
Linux's
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. One question currently remains open for me, both regarding your approach as well as my suggestion: What happens if some app links against more than onw skin library? I think your approach will cause multiple sigshadow_handler invocations (as the stack up due to library-local pthread_once), while mine suffers from multiple xeno_sigwinch_handler symbols. The latter might be solvable with __attribute__ ((weak)), correct? Yes, the pthread_once_t should be global with __attribute__((weak)), and we would get the proper behaviour for the proposed implementation too. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. Nope, the burden will still be Xenomai's, encoded in xeno_sigwinch_handler. The app will only have to check for its return code. Actually, I have no real preference. Philippe, since you designed the original code, could you tell us what you had in mind? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Hi,
here is a patch which implements the idea discussed previously of
re-using SIGWINCH to trigger priority changes in user-space. There is
only one patch, but the files should have been put in a logical order
to make review easier.
Since there are chances of conflicts with Jan patches series, I will
rebase this patch after Jan patches have been commited.
Here comes a newer version.
Index: include/nucleus/thread.h
===
--- include/nucleus/thread.h(revision 4251)
+++ include/nucleus/thread.h(working copy)
@@ -116,6 +116,7 @@
#define XNROBBED 0x0020 /** Robbed from resource ownership */
#define XNATOMIC 0x0040 /** In atomic switch from secondary to primary
mode */
#define XNAFFSET 0x0080 /** CPU affinity changed from primary mode */
+#define XNPRIOSET 0x0100 /** Priority changed from primary mode */
/* These information flags are available to the real-time interfaces */
#define XNTHREAD_INFO_SPARE0 0x1000
Index: include/asm-generic/syscall.h
===
--- include/asm-generic/syscall.h (revision 4251)
+++ include/asm-generic/syscall.h (working copy)
@@ -59,7 +59,12 @@ typedef struct xnsysinfo {
unsigned long tickval; /* Tick duration (ns) */
} xnsysinfo_t;
-#define SIGHARDEN SIGWINCH
+#define SIGSHADOW SIGWINCH
+#define SIGSHADOW_ACTION_HARDEN 1
+#define SIGSHADOW_ACTION_RENICE 2
+#define sigshadow_action(code) ((code) 0xff)
+#define sigshadow_prio(code) (((code) 8) 0xff)
+#define sigshadow_int(action, prio) ((action) | ((prio) 8))
#ifdef __KERNEL__
Index: include/nucleus/shadow.h
===
--- include/nucleus/shadow.h(revision 4251)
+++ include/nucleus/shadow.h(working copy)
@@ -99,6 +99,7 @@ void xnshadow_reset_shield(void);
void xnshadow_send_sig(struct xnthread *thread,
int sig,
+ int arg,
int specific);
void xnshadow_rpi_check(void);
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c (revision 4251)
+++ ksrc/nucleus/shadow.c (working copy)
@@ -115,6 +115,14 @@ do { \
switch_lock_owner[task_cpu(t)] = t; \
} while(0)
+#define xnshadow_sig_mux(sig, arg) ((sig) | (arg 8))
+#define xnshadow_sig_demux(muxed, sig, arg) \
+ do { \
+ int _muxed = (muxed);\
+ (sig) = _muxed 0xff; \
+ (arg) = _muxed 8; \
+ } while (0)
+
static struct task_struct *switch_lock_owner[XNARCH_NR_CPUS];
static int nucleus_muxid = -1;
@@ -879,7 +887,7 @@ static void xnshadow_dereference_skin(un
static void lostage_handler(void *cookie)
{
- int cpu = smp_processor_id(), reqnum, sig;
+ int cpu = smp_processor_id(), reqnum, sig, arg;
struct __lostagerq *rq = lostagerq[cpu];
while ((reqnum = rq-out) != rq-in) {
@@ -927,8 +935,16 @@ static void lostage_handler(void *cookie
case LO_SIGTHR_REQ:
- sig = rq-req[reqnum].arg;
- send_sig(sig, p, 1);
+ xnshadow_sig_demux(rq-req[reqnum].arg, sig, arg);
+ if (sig == SIGSHADOW) {
+ siginfo_t si;
+ memset(si, '\0', sizeof(si));
+ si.si_signo = sig;
+ si.si_code = SI_QUEUE;
+ si.si_int = arg;
+ send_sig_info(sig, si, p);
+ } else
+ send_sig(sig, p, 1);
break;
case LO_SIGGRP_REQ:
@@ -1237,6 +1253,13 @@ void xnshadow_relax(int notify)
/* Help debugging spurious relaxes. */
send_sig(SIGXCPU, current, 1);
+ if (xnthread_test_info(thread, XNPRIOSET)) {
+ xnthread_clear_info(thread, XNPRIOSET);
+ xnshadow_send_sig(thread, SIGSHADOW,
+ sigshadow_int(SIGSHADOW_ACTION_RENICE, prio),
+ 1);
+ }
+
#ifdef CONFIG_SMP
/* If the shadow thread changed its CPU affinity while in
primary mode, reset the CPU affinity of its Linux
@@ -1500,16 +1523,16 @@ void xnshadow_start(xnthread_t *thread)
schedule_linux_call(LO_START_REQ, p, 0);
}
+/* Called with nklock locked, Xenomai interrupts off. */
void xnshadow_renice(xnthread_t *thread)
{
- /* Called with nklock locked, Xenomai interrupts off. */
- struct task_struct *p = xnthread_archtcb(thread)-user_task;
-
/* We need to bound the priority values in the [1..MAX_RT_PRIO-1]
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. Nope, the burden will still be Xenomai's, encoded in xeno_sigwinch_handler. The app will only have to check for its return code. Actually, I have no real preference. Philippe, since you designed the original code, could you tell us what you had in mind? My reasoning at that time was that the application folks would not want or even be able to change the signal handling code to insert anything Xenomai might need, hence the override-then-route-unhandled approach. A typical configuration I thought of was GUI-based apps, that would include RT code as well. In that case, I don't think that most of us would want to be dragged into rebuilding kde/gtk libs, for the sole purpose of routing unhandled SIGSHADOW signals. At the same time, I agree with Jan that we should not prevent people who prefer hacking their own software components to install that routing in their handler, instead of fiddling with the order in which they do the application init chores. Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Philippe Gerum wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. Nope, the burden will still be Xenomai's, encoded in xeno_sigwinch_handler. The app will only have to check for its return code. Actually, I have no real preference. Philippe, since you designed the original code, could you tell us what you had in mind? My reasoning at that time was that the application folks would not want or even be able to change the signal handling code to insert anything Xenomai might need, hence the override-then-route-unhandled approach. A typical configuration I thought of was GUI-based apps, that would include RT code as well. In that case, I don't think that most of us would want to be dragged into rebuilding kde/gtk libs, for the sole purpose of routing unhandled SIGSHADOW signals. At the same time, I agree with Jan that we should not prevent people who prefer hacking their own software components to install that routing in their handler, instead of fiddling with the order in which they do the application init chores. Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, Mmm, that would not work for components running at late init stage though. AND document the shadow signal handler for people who can do #2? ... doing so would require to provide some Xenomai-specific marker in the siginfo struct the application-defined handler could test, but that should be doable. There is already such a marker: Xenomai nucleus use SI_QUEUE whereas the Linux kernel uses SI_KERNEL, for the siginfo member which-I-do-not-remember-the-name -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. Nope, the burden will still be Xenomai's, encoded in xeno_sigwinch_handler. The app will only have to check for its return code. Actually, I have no real preference. Philippe, since you designed the original code, could you tell us what you had in mind? My reasoning at that time was that the application folks would not want or even be able to change the signal handling code to insert anything Xenomai might need, hence the override-then-route-unhandled approach. A typical configuration I thought of was GUI-based apps, that would include RT code as well. In that case, I don't think that most of us would want to be dragged into rebuilding kde/gtk libs, for the sole purpose of routing unhandled SIGSHADOW signals. At the same time, I agree with Jan that we should not prevent people who prefer hacking their own software components to install that routing in their handler, instead of fiddling with the order in which they do the application init chores. Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: I wonder if we shouldn't switch the signal hooking strategy: So far we install the handler at shadow thread creation time, saving a potentially installed handler of the application for redirection of Xenomai-unrelated events. But that only works if the application installed the handler before it creates the first shadow thread, right? If the app decides to install/change the SIGWINCH handler later on (without taking care of our handler), we will loose. Suggestion: As this is fragile and cannot be solved transparently, lets document this signal requirement of Xenomai, e.g. in all task/thread creation functions of the skins. Tell the user that Xenomai will install a custom SIGWINCH handler and that, if the app wants to override it, it has to make sure to _first_ call into a Xenomai-provided handler and check if that one wants to handle the event. I'm thinking of something like int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt), where the return code is non-zero in case the signal was processed. With this policy in place, we can switch the signal handler installation above to __attribute__ ((construtor)) and save us all the changes regarding sigshadow_install below. You mean to push the burden of identifying the signal source and calling the proper handler on the user. With the current approach we take care of that burden, I think it is better. But I agree that this should be documented somewhere. Nope, the burden will still be Xenomai's, encoded in xeno_sigwinch_handler. The app will only have to check for its return code. Actually, I have no real preference. Philippe, since you designed the original code, could you tell us what you had in mind? My reasoning at that time was that the application folks would not want or even be able to change the signal handling code to insert anything Xenomai might need, hence the override-then-route-unhandled approach. A typical configuration I thought of was GUI-based apps, that would include RT code as well. In that case, I don't think that most of us would want to be dragged into rebuilding kde/gtk libs, for the sole purpose of routing unhandled SIGSHADOW signals. At the same time, I agree with Jan that we should not prevent people who prefer hacking their own software components to install that routing in their handler, instead of fiddling with the order in which they do the application init chores. Well, what about merging the solutions: trap the signal from the library constructor by default for people relying on #1, AND document the shadow signal handler for people who can do #2? For me, merging the two, would mean keep sigshadow_install called upon thread creation, but export xeno_sigwinch_handler to be callable from user signals. This way, if people install their signal handler before the first thread creation, they have nothing to worry about. If they install their signal handler at a later time, they have to take care of calling xeno_sigwinch_handler and look at its return value. Yes, hooking the SIGSHADOW within the lib ctor() would eventually be a bad idea. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Hi, here is a patch which implements the idea discussed previously of re-using SIGWINCH to trigger priority changes in user-space. There is only one patch, but the files should have been put in a logical order to make review easier. Since there are chances of conflicts with Jan patches series, I will rebase this patch after Jan patches have been commited. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.
Gilles Chanteperdrix wrote: Gilles Chanteperdrix wrote: Hi, here is a patch which implements the idea discussed previously of re-using SIGWINCH to trigger priority changes in user-space. There is only one patch, but the files should have been put in a logical order to make review easier. Since there are chances of conflicts with Jan patches series, I will rebase this patch after Jan patches have been commited. I'm reviewing those now, this should not be long. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
