On Tuesday, November 26, 2002, at 04:49 PM, Till Straumann wrote:
Hmm - a very good point. There might also be other RTEMS system/driver
tasks. I'm just wondering whether confining the epics accessible
priority range to a subrange of the RTEMS/vxWorks priorities is a good
solution? Having this restriction, a RT critical task may still not
be able to use the EPICS OSI thread API to obtain the priority it
needs...
BTW - Eric, I believe that the RTEMS interrupt message logger also runs
at the highest EPICS priority which is probably not really necessary.
O.K. What names should be added to epicsThead.h?
static const unsigned epicsThreadPriorityIocsh = 91;
static const unsigned epicsThreadPriorityNetwork = 91;
static const unsigned epicsThreadPriorityBaseMax = 91; <<< base-max,
jumbo-shrimp??? >>>
--
Eric Norum <[email protected]>
Department of Electrical Engineering
University of Saskatchewan
Saskatoon, Canada.
Phone: (306) 966-5394 FAX: (306) 966-5407
- References:
- Re: base max thread priority Till Straumann
- Navigate by Date:
- Prev:
Re: base max thread priority Till Straumann
- Next:
Re: base max thread priority Eric Norum
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
- Navigate by Thread:
- Prev:
Re: base max thread priority Till Straumann
- Next:
RE: base max thread priority Jeff Hill
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
|