Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Tue, 27 Nov 2012 20:59:25 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System