Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Tue, 26 Nov 2002 16:10:11 -0600

On Tuesday, November 26, 2002, at 04:03  PM, Till Straumann wrote:

Correct - but this could only happen if the insane task had a priority

> 91. However, if the user were to spawn a task with this high a

priority, he/she probably knew what he/she was doing: that task was

probably hard-rt critical and it was not tolerable to have it wait for

whatever

was going on at the console.

IMO, clamping everyghing to < 91 with the shell running at 91 is safe

- no runaway (base) task can lock the console. However, the user still

has the option of doing really critical work at a higher priority, if

necessary - at the risk of having a locked-up system should such a > task

run away, of course.

The benefit of leaving a range of priorities to the user IMO far

outweighs the possible damage.

Yes, running the shell at EPICS priority 91 seems reasonable.

Now another question. RTEMS, and I expect vxWorks as well, have system

tasks handling things like network I/O. What priority should these run

at? At the moment I've got the RTEMS network tasks at higher than the

highest EPICS task priority. From the above discussions it would seem

that running the network tasks at an RTEMS priority equivalent to EPICS

task priority 91 would be the right thing to do.

Comments?

--
Eric Norum <[email protected]>
Department of Electrical Engineering
University of Saskatchewan
Saskatoon, Canada.
Phone: (306) 966-5394   FAX:   (306) 966-5407

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System