Re: [Xenomai-core] [PATCH 1/1] Use SIGWINCH to trigger priority change in user-space.

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

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.

> 
>> One question currently remains open for me, both regarding your approach
>> as well as my suggestion: What happens if some app links against more
>> than onw skin library? I think your approach will cause multiple
>> sigshadow_handler invocations (as the stack up due to library-local
>> pthread_once), while mine suffers from multiple xeno_sigwinch_handler
>> symbols. The latter might be solvable with __attribute__ ((weak)), correct?
> 
> Yes, the pthread_once_t should be global with __attribute__((weak)), and
>  we would get the proper behaviour for the proposed implementation too.
> 

OK.

Nevertheless, the installation on thread creation remains fragile, IMHO.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]