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?