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 Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core