🚀 go-pugleaf

A. Hajderek wrote in message
<919712113.23201.0.nnrp-02.c2d9616c@news.demon.co.uk>...
>>Z tak pewna niesmialoscia pozwole sobie zauwazyc,
>>ze juz dosc dawno temu wymyslono cos takiego jak
>>priorytety procesow w sytemach operacyjnych .
>>Czyli jesli usuwanie smieci mialo by nizszy prirytet
>>to ryzyko spowolnienia znacznie maleje .
>
>
>Jak pan sobie wyobraza zarzadzanie odsmiecaniem
>realizowane przez dwa rozne procesy?
nie to mialem na  mysli , jesli mowa o realtime
i zdarzenich ktorych czas obslugi jest krytyczny
to programy ktore to robia sa pisane w ten
sposob ze alokuja pamiec (tworza obiekty)
w procesie inicjacji procesu i nie "bawia sie"
pamiecia podczas obslugi  zdarzen.
Nie jest tu specjalnie istotne czy bedzie
to w asm,C czy Javie.

Inne procesy (np. wizualizacja) alokuja
i zwalniaja pamiec (tworza i usuwaja obiekty)
i proces dsmiecania (dla Javy ) moze istotnie
dosc  mocno hamowac tempo ich pracy , ale
poniewaz procesy te maja nizszy priorytet
to sam proces odsmiecania nie blokuje
obslugi zdarzen krytycznych przez procesy
o wyzszych priorytetach (nawet jesli
wszystko bylo by w Javie)

>Poprzez "shared memory" + "semaphores"?
>Poprzez "pipes" albo "unix domain sockets"?
>Obawiam sie, ze moga to byc metody troche
>nieefektywne.

Niezaleznie od tego powyzej , na poziomie
jednego procesu automatyczne odsmiecanie
moge sobie wyobrazic albo jako usluge sytemowa
biegnaca w idle time lub jako dodatkowy watek
w procesie . Watek taki moze potencjanlnie
miec nizszy proiorytet niz glowny watek procesu.

Natomiast efektywnosc procesu biegnacego
na najnizszym poziomie priorytetu jest o tyle
istotna , ze procesor sie mniej lub wiecej "grzeje"
podczas idel time.


Mysle  wiec ,ze argument krytyki Javy z pozycji
real time  kontra odsmiecanie jest raczej chybiony.

pozdrawiam
patix