From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] rt_task_info.status encoding
Date: Fri, 17 Oct 2008 01:07:27 +0200 [thread overview]
Message-ID: <48F7C92F.2010509@domain.hid> (raw)
In-Reply-To: <48F7BF94.9050409@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]
prev parent reply other threads:[~2008-10-16 23:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-15 16:25 [Xenomai-core] rt_task_info.status encoding Jan Kiszka
2008-10-15 19:49 ` Philippe Gerum
2008-10-15 20:00 ` Gilles Chanteperdrix
2008-10-16 6:49 ` Jan Kiszka
2008-10-16 16:55 ` Philippe Gerum
2008-10-15 21:30 ` Jan Kiszka
2008-10-16 19:50 ` Philippe Gerum
2008-10-16 21:45 ` Jan Kiszka
2008-10-16 22:04 ` Gilles Chanteperdrix
2008-10-16 22:17 ` Jan Kiszka
2008-10-16 22:26 ` Gilles Chanteperdrix
2008-10-16 23:07 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48F7C92F.2010509@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.