Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: base max thread priority
From: Jeff Hill <johill@lanl.gov>
To: 'Till Straumann' <strauman@SLAC.Stanford.EDU>, 'Eric Norum' <eric.norum@usask.ca>
Cc: 'Marty Kraimer' <mrk@aps.anl.gov>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Tue, 26 Nov 2002 15:49:34 -0700

> I think we did this to ensure that you could still
> get some response at the console even if some other 
> task went insane and started gobbling CPU cycles. 

I've seen some valid arguments on both sides of this issue. 

If you run the shell at a higher priority then users can debug runaway
tasks. If you run the shell at a lower priority then its not possible
for some yuts to inadvertently disrupt all time critical record
processing for 5 minutes because he typed dbl without any arguments when
a database with 100,000 records was loaded. 

With R3.14 we can always directly attach the source level debugger to
debug runaway threads in an IOC that is running on a workstation. I
assume that this is also to a lesser extent possible with RTEMS and
vxWorks because the gdb debugging daemon must surely run at a very high
priority? 

If users are not fond of debugging runaway threads with a debugger then
a possible compromise, assuming there is support similar to Till's
enhancements for multiple simultaneous telnet shells on RTEMS, would be
to have a default shell running at a priority just above the CA server,
and another system administrator's shell running at the highest possible
priority. There would of course need to be some way to attach a terminal
window to the high priority system administrator's shell using telnet or
some serial device in the os, but this might require another OSI
interface. 

Admittedly, it might be difficult to attach either of the debugger or
the administrators shell if the IP kernel has failed or it isn't getting
any CPU. Considering that, then another possibility would be to run a
telnet (or os serial device routed) shell at a low priority and the boot
console at a high priority.

Jeff



Replies:
Re: base max thread priority Till Straumann
Re: base max thread priority Marty Kraimer
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 Jeff Hill
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: base max thread priority Till Straumann
Next: Re: base max thread priority Till Straumann
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·