From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48FB5CF4.20606@domain.hid> Date: Sun, 19 Oct 2008 18:14:44 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <48F9F12F.7090708@domain.hid> <48FB15A8.30703@domain.hid> <48FB17BD.7010904@domain.hid> <48FB1891.3060609@domain.hid> <48FB19F7.1030107@domain.hid> <48FB5BD5.1060205@domain.hid> In-Reply-To: <48FB5BD5.1060205@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space. Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Jan Kiszka , Xenomai core 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. -- Philippe.