<2002> 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | <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: base max thread priority |
From: | Marty Kraimer <[email protected]> |
To: | Eric Norum <[email protected]> |
Cc: | Jeff Hill <[email protected]>, 'Till Straumann' <[email protected]>, "'Johnson, Andrew N.'" <[email protected]> |
Date: | Wed, 27 Nov 2002 09:40:10 -0600 |
Eric Norum wrote:
Maybe something like: static const unsigned epicsThreadPriorityIocsh = 91; static const unsigned epicsThreadPriorityNetworkDaemons = 95;static const unsigned epicsThreadPriorityBaseMax = 91; <<<Still waiting for you folks to come up with a better name... >>>Then EPICS applications could still have priorities higher than the shell but lower than the network daemons, or even priorities higher than the network daemons as necessary.
Why not just have static const unsigned epicsThreadPriorityBaseMax = 91; Then iocsh could just use this as it's priority.epicsThreadPriorityNetworkDaemons doesn't sound like an epics base issue. It is an OS epecific issue, e.g. it is an RTEMS issue. If we add it it will, at least for now, be used only for RTEMS. Does it even make sense for systems where iocCore is running in user space? Thus at leats for now it will only apply to RTEMS.
On vxWorks I am really afraid of allowing any user thread to be higher priority than the network threads. This caused failures in the past.
Marty