Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority

[Andrew Johnson <anj@aps.anl.gov>]

Hi Till,

You have convinced me that dropping SCHED_FIFO should not be a problem, so all 
that remains is to get a portable implementation of the fix.

On 2012-11-27 Till Straumann wrote:
> On 11/27/2012 03:18 PM, Andrew Johnson wrote:
> >    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).

Ok, so you're saying the exec'd program would be able to switch back to 
SCHED_FIFO if it needs to; that's the main thing I was worrying about.

> > 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.

True, unless we had some kind of wrapper that would restart the caRepeater.  
However fixing osiSpawnDetachedProcess() as you suggest would be a simpler 
solution.

Do you have an implementation of the fix that is portable to all our Posix 
targets?  If I get one this week I might be able to get into 3.14.12.3.

- Andrew
-- 
Computer science is as much about computers as astronomy is about
telescopes. -- Edsger Dijkstra