Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System