On 11/27/2012 03:18 PM, Andrew Johnson wrote:
Hi Till,
On 2012-11-26 Till Straumann wrote:
The current implementation of posix/osiSpawnDetachedProcess()
basically just forks and execs. The new process inherits the
scheduling policy and priority of whoever called spawnDetachedProcess().
This means e.g., that a caRepeater spawned by a "real-time enabled"
IOC application executes under SCHED_FIFO with priority 51.
Not sure this is a good thing. IMO osiSpawnDetachedProcess()
should be fixed so that the new process starts out with SCHED_OTHER.
I doubt if there are many users of osiSpawnDetachedProcess() other than the
caRepeater, but I wouldn't want to break any that do exist which need to
inherit the SCHED_FIFO setting.
You could, however, also argue that there are probably very few (if any)
users out there who use the RT scheduler and they may be as surprised
by the current semantics as I am.
If the child process of the fork() were to
change to SCHED_OTHER before calling execlp() the new program might not have
the privilege necessary to switch back — is that correct?
IIRC this is not correct: resource limits are preserved across fork and
exec.
Hence, if the parent is able to use an RT priority so is the child. This
feature,
BTW, allows you e.g., to set the soft limit for RTPRIO from the shell which
executes a IOC process (provided that the sysadmin has given your shell a
high enough hard limit).
Personally I would solve the problem of having an RT-scheduled caRepeater by
ensuring that caRepeater always gets started when the system comes up before
the IOCs get run, say from an /etc/init.d script.
Of course, that was my first thought, too. However, what happens if
this caRepeater for some reason dies - wouldn't the RT-IOC try to
spawn a new one (now running under SCHED_FIFO)? This could lead
to ugly spurious real-time violations.
We could add another API that switches to SCHED_OTHER before the execlp() and
use that when starting the caRepeater, but I'm not sure about portability
I would be more radical and argue that the current behavior is actually
a bug which should be fixed. The newly created process inherits whatever
scheduling policy and priority the thread executing
osiSpawnDetachedProcess()
has. It makes IMHO no sense to pass a RT-priority on to a detached process
which by definition is something which is rather independent from the
parent.
If the new process has any RT needs (don't forget that any threads
created in
the child also inherit the policy/priority passed by the parent) then
they should
be carefully designed into the child and not carelessly passed on from
the parent.
- Till
What do you think?
- Andrew
- Replies:
- Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority Andrew Johnson
- References:
- posix osiSpawnDetachedProcess inherits scheduling policy + priority Till Straumann
- Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority Andrew Johnson
- Navigate by Date:
- Prev:
RE: Data acquisition for ICP accelerometers Mark Rivers
- Next:
Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority Till Straumann
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority Till Straumann
- Next:
Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|