Re: [Xenomai-core] rt_task_info.status encoding

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.

Other than that, I do not see what you mean.

-- 
					    Gilles.