On Oct 13, 10:10 am, Wojciech Jaczewski <w...@o...pl> wrote:
> Andrzej Jarzabek wrote:
>
> > Kolejny problem z deskryptorami jest taki, że łatwo przez pomyłkę o kod,
> > który w pewnych sytuacjach nie zamyka deskryptorów, które otwiera, np.
> > na wskutek early return czy rzucenia wyjątkiem.
>
> Jeśli akurat mi w danym momencie na czymś takim zależy i akurat używam C++,
> to robię klasę o nazwie fd_guard_t (analogiczną do lock_guard z nowego
> standardu). I dalej operuję na nie-opakowanym deskryptorze.

Lock guard jest specjalnie tak zrobiony, żeby ten sam lock mógł być
używany po wyjściu z zakresu, gdzie jest zalockowany przez tego
guarda. Zastosowanie tego samego narzedzia do deskryptora, gdzie
takich wymagań nie ma (nie masz sytuacji, gdzie po zamknięciu
deskruptora próbujesz go jeszcze raz otworzyć albo coś w tym stylu)
jest suboptymalne - co prawda rozwiązuje ci bezpośrednio ten problem,
ale umożliwia powstanie różnych błędów, które bez tego byłyby
niemożliwe - choćby że w trakcie modyfikacji kodu ktoś zmodyfikuje
zakresy tak, że deskryptor będzie zdefiniowany w innym niż jego lock,
albo ktoś gdzies wstawi zamykanie tego deskryptora ręcznie.

> > Dalej, jeśli np. próbujesz zrobić formatowane wyjście na deskryptor
> > przez ręczne babranie się z alokowaniem buforów, kopiowaniem i
> > sklejaniem stringów, jakimiś dodatkowymi funkcjami do formatowania
> > liczb, to masz całą masę pomyłek, które łatwo popełnić z katastrofalnymi
> > skutkami: dangling pointers, bufer overflow, memory leaks, czy dany
> > string jest null-terminated czy nie itd. itp.
>
> Do formatowania do pliku, czy na stdout, rzeczywiście może być wygodniejsze
> użycie FILE* lub iostream. Natomiast ich interfejs nie pasuje do sensownej
> obsługi np. połączeń sieciowych, gdzie przed wywołaniem funkcji nie wiadomo
> ile bajtów będzie się dało w tej chwili odczytać/zapisać. W takim wypadku
> lepszy jest jawny podział na dwie części: formatowanie do pamięci, a
> następnie przerzucenie w jednym lub wielu etapach przez deskryptor.

streambuf ma buforowanie, więc tak to właśnie raczej powinno działać.
Jednak musisz przyznać, że z punktu widzenia kogoś, kto chce
sfotmatować komunikat i przesłać go po połączeniu albo z kolei
odczytać komunikat zakończony np. CR-LF, niekoniecznie takie szczegóły
implementacyjne są interesujące.

> > Również dla sygnałów unixowych są abstrakcje, które będą zwykle
> > sensowniejsze do stosowania niż systemowe API, na przykład w modelu
> > programu, który obsługuje jakieś zdarzenia sygnał może wsytępować po
> > prostu jako jeden z typów "zdarzeń".
>
> Można. Z tym że nie wiem, czemu miałoby to być "sensowniejsze". Jest tak
> samo sensowne jak POSIX-owe, tylko z innym interfejsem.

Sensowniejsze o tyle, że masz rodzieloną logikę mówiącą jak na jakieś
zdarzenie trzeba reagować z samą obsługą i rozstrzyganiem tego, na co
jak trzeba zareagować. W związku z tym komuś dodającemu nowy typ
zdarzenia do obsługi trudniej będzie zepsuć jakiś aspekt istniejącej
logiki, niż jeśli modyfikuje dużą pętlę z 'jeśli sygnał to tamto,
jeśli coś na sockecie to śmamto, jeśli minęło tyle czasu to owamto".

> > Kolejne unixowe API którego łatwo przez pomyłkę użyć nieprawidłowo i
> > rozwalić program to choćby pthreads.
>
> Wątków akurat unikam jak mogę. Łatwiej się testuje dwa współpracujące
> procesy, niż dwa współpracujące wątki. API opakowujące pthreads nie
> wniosłoby mi w tej kwestii absolutnie nic.

W rzeczywistości wątków się używa bo to wydajny i elastyczny sposób na
zrównoleglenie aplikacji. W przypadku stosowania oddzielnych procesów
samo kszta związane z narzutem na ich odpalanie, IPC itd. często
zabijają wszelkie korzyści ze zrównoleglenia.

> >> Oczywiście w każdym API dałoby się wskazać jakieś wady, ale na jakiej
> >> podstawie miałbym przypuszczać, że zrobiona w dużo krótszym czasie
> >> abstrakcja będzie istotnie lepsza?
>
> > Dlaczego zakładasz, że w dużo krótszym czasie?
>
> Porównuję do czasu od którego istnieją systemy Uniksowe. Większość założeń
> jest już bardzo starych, ale jednak przez bardzo wiele lat standard się
> jeszcze rozwija.

Owszem, standard się rozwija, ale zachowanie wsteczniej
kompatybilności z latami 70-tymi jest ważniejsze niż tworzenie
lepszych abstrakcji. Raczej bym powiedział, że rozwój koncentruje się
na dostarczaniu nowej funkcjonalności, słusznie zakładając, że
potrzeba abstrakcji będzie zaspokojona przez biblioteki opakowujące.
Już nie mówiąc o tym, że API jest w C, a to język dosyć kiepsko
nadający sie do wyrażania abstrakcji czy budowania struktur
wspierających niezawodność.

> > Nie znam Qt, więc się nie wypowiem. Zapewne ewidentną zaletą tago
> > rozwiązania jest to, że nie da się pomylić inta zawierającego deskryptor
> > z intem zawierający liczbę przeczytanych bajtów.
>
> Nie widziałem jeszcze przypadku pomylenia inta zawierającego deskryptor z
> intem zawierającym liczbę przeczytanych bajtów. Ta zaleta jest czysto
> teoretyczna.

Ja widziałem wiele przypadków błedów spowodowanych pomyleniem x-a
robiącego A z x-em robiącym B przez kogoś, kto nigdy przedtem nie
widział takiego przypadku. Mnie też to oczywiście wiele razy
dotyczyło.