Pracuję nad dużym projektem C ++. Składa się z serwera, który udostępnia interfejs API REST, zapewniając prosty i przyjazny interfejs dla bardzo szerokiego systemu zawierającego wiele innych serwerów. Baza kodów jest dość duża i złożona i ewoluowała w czasie bez odpowiedniego projektu z góry. Moim zadaniem jest wdrażanie nowych funkcji i refaktoryzacja / naprawa starego kodu, aby uczynić go bardziej stabilnym i niezawodnym.
W tej chwili serwer tworzy wiele długo żyjących obiektów, które nigdy nie są kończone ani usuwane po zakończeniu procesu. To sprawia, że Valgrind jest prawie bezużyteczny do wykrywania wycieków, ponieważ nie można odróżnić tysięcy (wątpliwie) uzasadnionych wycieków od „niebezpiecznych”.
Moim pomysłem jest upewnienie się, że wszystkie obiekty zostaną usunięte przed zakończeniem, ale kiedy złożyłem tę propozycję, moi koledzy i mój szef sprzeciwili się mi, wskazując, że system operacyjny i tak zwolni tę pamięć (co jest oczywiste dla wszystkich) i usuwając obiekty spowolni zamykanie serwera (co w tej chwili jest w zasadzie wezwaniem do std::exit
). Odpowiedziałem, że „czysta” procedura zamykania niekoniecznie oznacza, że trzeba z niej skorzystać. Zawsze możemy zadzwonić std::quick_exit
lub po prostu kill -9
proces, jeśli czujemy się niecierpliwi.
Odpowiedzieli: „większość demonów i procesów Linuksa nie zawraca sobie głowy zwalnianiem pamięci podczas zamykania”. Chociaż widzę to, prawdą jest również to, że nasz projekt potrzebuje dokładnego debugowania pamięci, ponieważ już znalazłem uszkodzenie pamięci, podwójne zwolnienia i niezainicjowane zmienne.
Jakie są Twoje myśli? Czy dążę do bezcelowego przedsięwzięcia? Jeśli nie, jak mogę przekonać moich kolegów i szefa? Jeśli tak, dlaczego i co powinienem zamiast tego zrobić?