In message <[EMAIL PROTECTED]>, Bruce Ev
ans writes:
>> > Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
>> > other user processes from running like a system process might do:
>> >
>> > idprio 31 sh -c "while :; do :; done"
>> >
>> > System processes actually hang the entire system until they complete:
>>
>> Are you mixing idprio with rtprio or did I not understand what you
>> explain?
>
>You didn't understand :-). Try the example. It only uses idprio.
>
>rtprio certainly causes system hangs, and the supergiant lock may
>increase the problem. Before SMPng, rtprio processes prevented all
>non-rtprio processes including important daemons (and I think even
kernel processes) from running. Starting an infinite loop at rtprio
>while remotely logged in was fatal because a ^C (character, not signal)
>to kill the process couldn't be delivered.
I can confirm this one, ntpd has for a long time pointlessly raised
it's priority to the absolute maximum, and if during debugging it
went into a spin it would freeze the system.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
