On Thu, 9 Aug 2007, Rados?aw Sokó? wrote:
> To zależy od architektury systemu. Jeżeli np. GUI telefonu
> będzie zrealizowane jako osobny proces, przełączeń będzie
> mnóstwo i będzie to nieefektywne, ale całość będzie niesamo-
No nie przesadzaj z tym "mnostwo" -- kwant szeregowania moze byc dosc
duzy, rzedu np. 50ms, a przelaczenia i tak beda nastepowac jedynie w
przypadku jednoczesnego zapotrzebowania na czas procesora ze strony co
najmniej dwu procesow.
Nie mowie tu o kwestiach takich jak obsluga przerwan -- jesli dedykujemy
oddzielny rdzen do obslugi zdarzen asynchronicznych, to mozna sobie nimi w
ogole glowy nie zaprzatac (ale wtedy rownie dobrze mozna system podzielic
inaczej i dedykowac jeden rdzen dla GUI, a drugi dla jadra), a jesli
dysponujemy tylko jednym rdzeniem, to ich obsluga wymusza koszt zblizony
do kosztu przelaczenia kontekstu (przelaczen kontekstu mozna w miare
mozliwosci dokonywac "przy okazji" przerwan, wiec czas na te pierwsze
zostanie skonsumowany).
> wicie stabilna. GUI w jądrze będzie znacznie szybsze, ale
> z lekkim ryzykiem, że jedna aplikacja będzie mogła sporo
> namieszać. GUI jako biblioteka aplikacji będzie najszybsze
> i bez zmiany uprzywilejowania, ale jeden proces powiesi
> całe urządzenie.
Co rozumiesz pod pojeciem "biblioteka aplikacji"? Program typu "wszystko
w jednym"? I tak trzeba go umiescic na ktoryms z poziomow -- albo jadra,
albo uzytkownika.
Ja tam wietrze zupelnie inna przyczyne...
> Zakładamy, że będzie dobrze, a jak nie będzie dobrze, to
> reset. Nie jest to tak zupełnie bez sensu.
Jesli zalozeniem jest, ze taki reset to ostatecznosc, to w porzadku --
czasem moze sie cos zdarzyc, np. zawsze moze przelatywac obok jaka czastka
elementarna i przestawic jakis istotny bit informacji. Jesli zalozeniem
jest, ze nie ma o co sie martwic, bo jakby co, to "watchdog" posprzata, to
niewesolo...
Maciej
Received on Fri Aug 10 16:15:07 2007
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Fri 10 Aug 2007 - 16:51:12 MET DST