Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> I start to believe we are arguing with different (miss-)use case in >>>> mind. Mine is definitely not about "helping" the user to switch the >>>> thread mode even more actively. It is about validating application >>>> states, it is about thread state reflection without any other actions >>>> than reporting errors. T_PRIMARY is part of the picture for the dual >>>> kernel Xenomai version, and it will remain such as long as there are two >>>> kernels. Even better, it is a very helpful application debugging tool >>>> when it comes to runtime validation of their real-time behavior. Again, >>>> it is NOT about promoting more use of rt_task_set_mode! >>> SIGXCPU may be used validate current thread mode, and it has the >>> advantage that it can not be misused. >> You are not always able to install or switch signal handlers when >> crossing application module boundaries. And you can't use it to validate >> the opposite (RT thread calls into lengthy, not RT-context suited >> library function). > > For me, one problem of SIGXCPU is when one non RT thread acquires a > mutex shared with a RT thread, and then calls some functions which cause > it to switch to secondary mode. But we could conceivably modify the > nucleus to detect this kind of situation. > > Another problem is that malloc, free, new and delete do not necessarily > cause a switch to secondary mode. But this also could conceivably be > solved by wrapping/overriding these calls and call the SIGXCPU handler > in the wrapper.
Yes, and add getimeofday to this list. Even worse: When it triggers, the backtrace stops in the vsyscall page, not allowing to identify the caller. > > Other than that, I do not see what you mean. SIGXCPU becomes useless if you are unable to install a signal handler, e.g. from within an invoked library. rt_task_inquire is then an alternative mechanism to add debug assertions. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
