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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core