Przenośne środowisko wykonawcze Netscape — Netscape Portable Runtime

Przenośne środowisko wykonawcze Netscape
Deweloper(zy)	Fundacja Mozilla / Korporacja Mozilla
Wersja stabilna	4.32 /30 czerwca 2021 ; 18 dni temu
Magazyn
Napisane w	do
System operacyjny	Wieloplatformowy
Rodzaj	Biblioteka oprogramowania
Licencja	MPL
Stronie internetowej	programista .mozilla .org /docs /NSPR

W informatyce , Netscape Portable Runtime lub NSPR , biblioteka abstrakcji platformy , sprawia, że wszystkie obsługiwane przez nią systemy operacyjne wyglądają tak samo (na przykład) dla przeglądarek internetowych w stylu Mozilli . NSPR zapewnia niezależność platformy dla obiektów systemu operacyjnego bez graficznego interfejsu użytkownika . Obiekty te obejmują:

wątki
synchronizacja wątków
normalne wejścia/wyjścia plików i sieci
czas interwału i czas kalendarzowy
podstawowe zarządzanie pamięcią ( malloc i free)
łączenie bibliotek współdzielonych .

Znaczna część biblioteki, a być może także jej ogólny wpływ na środowisko Gromit , stanowi podstawę wirtualnej maszyny Javy , mniej więcej odwzorowując warstwę sys, którą Sun definiuje w celu przenoszenia Java VM na różne platformy . NSPR wykracza poza ten wymóg w niektórych obszarach, ponieważ działa również jako warstwa niezależna od platformy dla większości serwerów produkowanych przez Netscape .

Historia

Pierwsza generacja NSPR pierwotnie miała na celu spełnienie wymagań związanych z przenoszeniem Javy do różnych środowisk hostów. NSPR20, wysiłek rozpoczęty w 1996 roku, zbudowany na tym oryginalnym pomyśle, choć niewiele pozostało z oryginalnego kodu. („20” w „NSPR20” nie oznacza „wersji 2.0”, ale raczej „drugą generację”). Wiele koncepcji wskazuje na reformę, ekspansję i dojrzewanie. W 2009 roku NSPR nadal funkcjonował poprawnie jako warstwa zależna od platformy pod Javą, ale służył również do obsługi klientów napisanych w całości w C lub C++ .

Jak to działa

Celem NSPR jest zapewnienie jednolitej obsługi w szerokim zakresie środowisk systemów operacyjnych. Stara się nie eksportować najniższego wspólnego mianownika, ale wykorzystać najlepsze cechy każdego systemu operacyjnego, na którym działa, jednocześnie zapewniając jednolitą usługę w szerokim zakresie ofert hostów.

Wątki

Wątki zajmują poczesne miejsce w NSPR. Przez przemysł oprogramowania dydaktycznego ofiara wątków brakuje spójności. NSPR, choć daleki od doskonałości, zapewnia pojedynczy interfejs API, do którego klienci mogą programować i oczekiwać w miarę spójnego zachowania. Systemy operacyjne zapewniają wszystko, od braku koncepcji wątków do zaawansowanych, skalowalnych i wydajnych implementacji włącznie. NSPR wykorzystuje w jak największym stopniu to, co oferują systemy. NSPR ma na celu nałożenie jak najmniejszego narzutu na dostęp do odpowiednich funkcji systemu.

Synchronizacja wątków

Synchronizacja wątków luźno zależy od monitorów, jak opisał CAR Hoare w „Monitors: An Operating system structuring concept”, Communications of the ACM , 17(10), październik 1974, a następnie sformalizowana przez język programowania Xerox ’ Mesa („Mesa Language Manual”, JG Mitchell i in., Xerox PARC, CSL-79-3 (kwiecień 1979)). Mechanizm ten zapewnia podstawowe funkcje wzajemnego wykluczania ( mutex ) i powiadamiania o wątkach (zmienne warunkowe) zaimplementowane przez NSPR. Ponadto NSPR zapewnia metody synchronizacji bardziej odpowiednie do wykorzystania przez Javę. Funkcje podobne do Javy obejmują możliwość ponownego wejścia monitora, niejawne i ściśle powiązane możliwości powiadamiania z możliwością dynamicznego kojarzenia obiektów synchronizacji.

We/Wy

We /wy NSPR nieznacznie rozszerza model gniazd Berkeley i pozwala na dowolne nakładanie warstw. Projektanci pierwotnie zamierzali eksportować tylko synchroniczne metody we/wy, opierając się na wątkach, aby zapewnić współbieżność potrzebną do złożonych aplikacji. Ten sposób działania pozostaje preferowany, chociaż można skonfigurować sieciowe kanały I/O jako nieblokujące w tradycyjnym sensie.

Adresy sieciowe

Część NSPR dotyczy manipulacji adresami sieciowymi. NSPR definiuje obiekt adresu sieciowego zorientowanego na IP . Chociaż nie definiuje obiektu jako nieprzezroczystego, interfejs API udostępnia metody, które umożliwiają i zachęcają klientów do traktowania adresów jako elementów polimorficznych . W tym obszarze NSPR ma na celu zapewnienie ścieżki migracji między IPv4 i IPv6 . W tym celu można dokonać translacji ciągów ASCII ( nazw DNS ) na struktury adresów sieciowych NSPR, niezależnie od tego, czy technologia adresowania wykorzystuje IPv4 czy IPv6.

Czas

NSPR udostępnia funkcje pomiaru czasu w dwóch formach: pomiaru czasu interwałowego i funkcji kalendarza.

Liczniki interwałów są oparte na darmowym, 32-bitowym, zależnym od platformy liczniku czasu rozdzielczości. Takie zegary są zwykle używane do określania limitów czasu na I/O, oczekiwania na zmienne warunkowe i innych podstawowych harmonogramów wątków. Ponieważ te czasomierze mają skończoną przestrzeń nazw i działają swobodnie, można je zawijać w dowolnym momencie. NSPR nie podaje epoki , ale oczekuje, że klienci poradzą sobie z tym problemem. Gwarantowana ziarnistość liczników wynosi od 10 mikrosekund do 1 milisekundy. Pozwala to na minimalny czas timera wynoszący około 12 godzin. Ale aby poradzić sobie z problemem zawijania, można wykorzystać tylko połowę tej przestrzeni nazw. Dlatego minimalny interwał dostępny z timerów wynosi nieco mniej niż sześć godzin.

Godziny kalendarzowe to 64-bitowe liczby ze znakiem z jednostkami mikrosekund. Epoka dla czasów kalendarzowych to północ, 1 stycznia 1970, czas uniwersalny Greenwich . Czasy ujemne obejmują czasy przed 1970 r., a liczby dodatnie do przodu. Użycie 64 bitów pozwala na reprezentację czasów w przybliżeniu w zakresie od -30000 do 30000. Wychodzi strukturalna reprezentacja (tj. widok rozstrzelony), procedury pobierające aktualny czas z systemu hosta i konwertujące je na i z 64-bitowa i strukturalna reprezentacja. Dodatkowo istnieją procedury konwersji do iz większości znanych form ASCII na 64-bitową reprezentację NSPR.

Zarządzanie pamięcią

NSPR zapewnia API do wykonywania podstawowych funkcji malloc , calloc , realloc i free . W zależności od platformy funkcje mogą być zaimplementowane niemal w całości w środowisku wykonawczym NSPR lub po prostu podkładki, które od razu odwołują się do oferty systemu operacyjnego hosta.

Łączenie

Obsługa łączenia (ładowanie i rozładowywanie biblioteki współdzielonej) stanowi część zestawu funkcji NSPR. W większości przypadków jest to po prostu wygładzenie udogodnień oferowanych przez różnych dostawców platform.

Languages

In other projects