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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to