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