🚀 go-pugleaf

Andrzej Lewandowski wrote:
> Poruszamy sie na gruncie nieporozumien semantycznych. Rzeczywiscie,
> jezeli aplikacja zatrzymuje sie sama (ponizej 100% obciazenia) to
> trudno zwalic wine na odsmiecacz ze ja zatrzymuje.

100% obciazony system czasu rzeczywistego to jest albo awaria
albo blad projektu. Poprawnie zaprojektowany system NIGDY nie
dziala na 100% obciazenia, z wyjatkiem sytuacji, ktore sa poza
zakresem stanow, na ktore zostal zaprojektowany. Jest to
fundamentalna wlasciwosc systemow czasu rzeczywistego.

> Natomiast koncept
> ze zadanie zostanie odrzucone bo zabraklo dla niego pamieci z tego
> prostego powodu ze odsmiecacz nie zdazyl odsmiecic mimo ze
> potencjalnie pamiec byla dostepna, wydaje sie malo atrakcyjny.

W przypadku routera/gatewaya, ktory opisalem wczesniej jest to
jedno z zalozen projektowych: 'graceful degradation' (po polsku
okresla sie to chyba jako 'lagodny upadek'). Prosze zauwazyc,
ze procesy obslugujace istniejace polaczenia, ktore nie przydzialaja
nowej pamieci, dzialaja bez jakichkolwiek zaklocen.

W ogolnym przypadku, brak wolnej pamieci stertowej to taki sam
blad projeku systemu jak np. niedostateczny rozmiar pamieci
stosu.

Sylwester