Czy system Windows dba o zamykanie gniazd po wyjściu procesów?

12

Przeczytałem to pytanie o Linuksie. Czy port może zostać powiązany po zakończeniu procesu?
Linux wydaje się czyścić po zakończeniu procesów i pozostawieniu otwartych gniazd. Zastanawiałem się, czy jest jakaś specyfikacja tego, jak to działa w systemie Windows. Czy system operacyjny konsekwentnie dba o zamykanie gniazd dla procesów, które wychodzą bez ich zamykania?

Simone
źródło

Odpowiedzi:

10

Zarówno w systemie Windows, jak i Unixen, po wyjściu z procesu jądro zamyka wszystkie otwarte uchwyty.

Windows NT

Zakończenie procesu - MSDN

Zakończenie procesu ma następujące wyniki:

  • [...]
  • Wszelkie zasoby przydzielone przez proces są zwalniane.
  • Wszystkie obiekty jądra są zamknięte.
  • [...]

Podczas gdy otwarte uchwyty do obiektów jądra są zamykane automatycznie po zakończeniu procesu, same obiekty istnieją, dopóki wszystkie otwarte uchwyty do nich nie zostaną zamknięte. Dlatego obiekt pozostanie ważny po zakończeniu procesu, który go używa, jeśli inny proces ma otwarty uchwyt.

ExitProcessfunkcja - MSDN

Wyjście z procesu powoduje:

  • [...]
  • Wszystkie uchwyty obiektów otwarte przez proces są zamknięte.
  • [...]

Linux

exit(3) - Podręcznik programisty systemu Linux (funkcje libc)

Wszystkie otwarte strumienie stdio (3) są opróżniane i zamykane.

_exit(2) - Podręcznik programisty Linuksa (wywołania systemowe jądra)

Funkcja _exit()kończy proces wywoływania „natychmiast”. Wszelkie otwarte deskryptory plików należące do procesu są zamknięte; wszystkie elementy potomne procesu są dziedziczone przez proces 1, init , a rodzic procesu otrzymuje sygnał SIGCHLD.


Pamiętaj, że w obu systemach operacyjnych

  1. Gniazda są tylko jednym rodzajem deskryptorów plików (FD) / obiektów jądra, więc powyższe dotyczy w równym stopniu plików i gniazd.

  2. Opisy plików w systemie UNIX, a także uchwyty Object Kernel obiekty w systemie Windows, może być w posiadaniu wielu procesów - oni ich uchwyty mogą być dziedziczone przez procesy potomne, a nawet przeszedł dookoła za pomocą specjalnych funkcji IPC.

  3. Plik lub gniazdo są zamykane tylko wtedy, gdy wszystkie dyski wskazujące do niego są zniszczone.

użytkownik1686
źródło
2
Gniazda TCP są szczególnym przypadkiem ze względu na ich stany TIME_WAIT. Na przykład, jeśli zakończysz aplikację nasłuchującą na porcie TCP, często nie możesz natychmiast połączyć się z tym samym portem.
haimg
2
Nie. Deskryptory plików i uchwyty obiektów są własnością i są dostępne tylko dla jednego procesu i są jednostkami ściśle dla poszczególnych procesów . Jest to opis pliku i podstawowy obiekt, które są współużytkowane przez procesy.
JdeBP
5

W systemie Windows gniazdo jest łącznikiem między punktem końcowym komunikacji a procesem. Właśnie dlatego, gdy duplikujesz gniazdo, kończysz z dwoma gniazdami, ale tylko jednym punktem końcowym. Dlatego nie można przekazać gniazda z jednego procesu do drugiego bez utworzenia nowego gniazda w drugim procesie.

Jeśli proces przestanie istnieć, jego gniazda koniecznie przestaną istnieć. Nie ma koncepcji gniazda bez procesu do jego utrzymania. Dlatego nawet sterowniki jądra systemu Windows, które chcą tworzyć gniazda na poziomie jądra, muszą określać proces będący właścicielem gniazda lub wywoływać funkcję z kontekstu procesu, który może być właścicielem gniazda. (Lub mogą bezpośrednio manipulować punktami końcowymi bez użycia gniazd).

Twoje pytanie wydaje się naprawdę nie dotyczyć gniazd, ale samych punktów końcowych komunikacji. Gniazdo ma odniesienie do punktu końcowego komunikacji. Kiedy gniazdo znika, liczba referencyjna spada. Jeśli osiągnie zero, zostanie usunięty, gdy tylko będzie to dozwolone, biorąc pod uwagę wymagania protokołu komunikacyjnego, z którym powiązany jest punkt końcowy. TCP ma stan TIME_WAIT, w którym punkt końcowy musi być utrzymywany w pobliżu, aby obsłużyć wszelkie „pozostałe” pakiety.

David Schwartz
źródło
3

Tak. W ten sposób wyczuwa się system Windows 3.1 95 98 XP (przynajmniej wiem na pewno od XP).

Scott Chamberlain
źródło
1
Nie, nie ma. Być może od wersji Windows NT 3. 5 . Ale DOS-Windows był zupełnie innym zwierzęciem niż Windows NT, jeśli chodzi o gniazda; i DOS-Windows 95 różniły się znacznie od DOS-Windows 3.1. Aplikacje Win16 były wymagane do wywołania w WSACleanup()przeciwnym razie nastąpiły wycieki; w DOS-Windows 9x pojawił się paskudny problem, udokumentowany w artykule MSKB nr 156319, z procesami nadrzędnymi unieważniającymi gniazda przekazywane do ich dzieci, spowodowane przez dość odmienną semantykę wyjścia procesowego dla gniazd przez DOS-Windows.
JdeBP
1
@JdeBP: A co z Windows NT 3. 1 - czy wykonał automatyczne czyszczenie?
user1686,
1
3.1 nie miał w ogóle gniazd.
JdeBP
... Dobra uwaga, @JdeBP - Nie myślałem o tym.
user1686
@JdeBP Zaktualizowano odpowiedź, aby ją poprawić.
Scott Chamberlain