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.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to