Bernd Walter <ticso(at)cicely12.cicely.de> wrote:
> Du bist dir aber durchaus darüber im klaren, dass ein hängender rtprio
> Prozess die gesammte Maschine lahm legt?
Das habe ich schon mehrfach erlebt. Besonders in Erinner-
ung ist mir die »Rettungsaktion« eines Kollegen geblieben,
der bash-Liebhaber war ... es ging um einen überlasteten
Server, der nur noch sehr langsam antwortete, und wohl meh-
rere Sekunden brauchte, um nach jedem Kommando wieder sei-
nen langen, mehrfarbigen Shellprompt zu malen. Um das zu
beschleunigen, gab er »rtprio 0 $$« ein ... Böser Fehler,
wie sich kurz darauf herausstellte, denn seine bash-Beta-
Version war wohl noch nicht von allen Endlosschleifen be-
reinigt ... :-)
> Ich würde das bei komplexen Programmen wie MP3 encodern nicht in
> Betracht ziehen - genaugenommen mag ich das Features überhaupt nicht.
Ja, auch die FreeBSD-Entwickler mögen es überwiegend nicht.
rtprio und idprio sind ursprünglich nur Nebenprodukte des
Schedulers, und wurden dann nur widerwillig »mitgezogen«.
Es gab in -current immer wieder längere Phasen, wo sie
überhaupt nicht funktionierten, und wo Matt Dillon dann
nach ein paar Wochen meinte: »Achja, ich hatte gerade 'ne
halbe Stunde Zeit; jetzt gehen auch idprio/rtprio wieder.«
Auch ich würde rtprio meiden, wenn irgend möglich. Wenn
man wirklich mal einen Fall hat, wo zwei Prozesse um die
CPU kämpfen und man den einen nicht mit nice bändigen kann
(was aber eigentlich nicht passieren dürfte), dann würde
ich nicht den wichtigeren mit rtptio behandeln, sondern den
anderen mit idprio. Das ist weniger gefährlich.
Gruß
Olli
-- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Mon 11 Oct 2004 - 14:56:25 CEST