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?


Xenomai-core mailing list

Reply via email to