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


Xenomai-core mailing list

Reply via email to