All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] rt_task_set_priority vs. Linux priority
Date: Thu, 02 Oct 2008 18:45:57 +0200	[thread overview]
Message-ID: <48E4FAC5.9040003@domain.hid> (raw)
In-Reply-To: <48E4F457.4000004@domain.hid>

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> AFAIC, I don't see how changing priorities on the fly within a time critical
>> section could be considered as good programming practice; this would tend to
>> indicate that somebody is playing with priorities to paper over an application
>> design issue.
> 
> So, you mean PIP papers over application design issues ? Just kidding...
>

PIP means, "well, you know what, I don't want to deal with dynamic resource
conflicts in my application, I don't want to bother defining a ceiling priority
for each of those resources, actually, I'm just unable to tell how they might
interact anyway, so please, beautiful and inspired kernel, GET THIS DAMNED THING
RIGHT FOR ME! Oh, and thank you."

But hey, that's fine! Nothing prevents the kernel from doing the smart job, anyway.

> 
>> For that reason, enduring a mode switch upon
>> rt_task_set_priority() calls (and friends) would be ok for me. But that's
>> certainly debatable.
> 
> Actually, we could trigger a signal for pthread_setschedparam to be
> called for next switch to secondary mode. We could re-use the signal
> already used to trigger a switch to primary mode for suspending a thread
> running in secondary mode, finding a way to multiplex the information
> passing, for instance, parameters to the siginfo structure.
> 

Yep, that would work.

-- 
Philippe.


      parent reply	other threads:[~2008-10-02 16:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-02 15:51 [Xenomai-core] rt_task_set_priority vs. Linux priority Jan Kiszka
2008-10-02 15:52 ` Gilles Chanteperdrix
2008-10-02 16:06   ` Gilles Chanteperdrix
2008-10-02 16:06   ` Jan Kiszka
2008-10-02 16:10     ` Gilles Chanteperdrix
2008-10-02 16:18       ` Jan Kiszka
2008-10-02 16:30         ` Philippe Gerum
2008-10-02 16:37           ` Gilles Chanteperdrix
2008-10-02 16:48             ` Philippe Gerum
2008-10-02 16:12   ` Philippe Gerum
2008-10-02 16:18     ` Gilles Chanteperdrix
2008-10-02 16:23       ` Jan Kiszka
2008-10-02 16:26         ` Jan Kiszka
2008-10-02 16:45       ` Philippe Gerum [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=48E4FAC5.9040003@domain.hid \
    --to=rpm@xenomai.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=jan.kiszka@domain.hid \
    --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.