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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: posix osiSpawnDetachedProcess inherits scheduling policy + priority |
From: | Till Straumann <[email protected]> |
To: | "Hill, Jeff" <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | 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 1000attempts 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