george anzinger <george@mvista.com> wrote:
>
> If the issue is regaining control after some RT task goes into a loop,
> the way this is usually done is to keep a session around with a higher
> priority. Using this concept, one might provide tools that, from
> userland, insure that such a session exists prior to launching the
> "suspect" code. I fail to see the need for this sort of code in the
> kernel.
That works, until your shell calls ext3_mark_inode_dirty(), which blocks on
kjournald activity. kjournald is SCHED_OTHER, and never runs...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:25 EST