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

Reply via email to