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.

> 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.


Xenomai-core mailing list

Reply via email to