Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Tue, 27 Nov 2012 22:37:52 -0600

On 11/27/2012 04:34 PM, Hill, Jeff wrote:

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.

I'm ok with adding a new function called osiSpawnDefaultAttributeDetachedProcess() for use with starting the ca repeater, and documenting also that the intent of osiSpawnDetachedProcess will be to create a process inheriting most of the calling processes attributes.

I have said most I wanted to say in my last post.
Let me just add here that passing process attributes is probably
OK. However, the scheduling policy and priority are attributes of
the particular thread which calls osiSpawnDetachedProcess() and
they are inherited by the entire child process.
I don't think this is appropriate. The detached process should be
created using SCHED_OTHER. Another problem with the current
scheme I have is that the potentially expensive 'fork' and 'exec' are
executing with a real-time priority.

Hard to measure exactly but getrusage() reports a loop of 1000

attempts to osiSpawnDetachedProcess("/bin/true") (1GHz pentium M running

linux

with RT_PREEMPT) to use rougly 0.55 seconds ('system time'), i.e.,
500us per call. Not good.

IMO 'osiSpawnDetachedProcess()' should be fixed so that the calling
thread temporarily switches to SCHED_OTHER until the call returns
(or simply creates a new thread with SCHED_OTHER policy which then
forks).

Till

Jeff

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Andrew Johnson
Sent: Tuesday, November 27, 2012 2:19 PM
To: [email protected]
Subject: Re: posix osiSpawnDetachedProcess inherits scheduling policy +
priority

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

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.

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.

What do you think?

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System