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,

Mało prawdopodobne, aby w wyniku zwykłej pomyłki a nie celowego psucia
rozdzielić taką sekwencję do osobnych bloków:

int fd = jakas_tam_metoda_tworzenia_fd();
fd_guard_t fd_guard(fd);

> albo ktoś gdzies wstawi zamykanie tego deskryptora ręcznie.

Opakowanie deskryptora w obiekt też wiele na to nie pomoże, bo np. dalsza
część funkcji chciała coś wysłać przez deskryptor, a on zamknięty.

> 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.

Są interesujące, jeśli nie chce aby użytkownik przy jego programie ćwiczył
swoją cierpliwość - gdy akurat przywiesiło się połączenie.
Albo załóżmy, że mamy prosty protokół, gdzie każda ze stron, na przemian
wysyła po jednej lub więcej linii tekstu. Za pomocą interfejsów istream tego
się nie odbierze, bo nie wiadomo ile linii zostało przysłanych.

> 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".

Wszystko zależy od przypadku. Czasem lepiej widać co się dzieje, gdy
wszystkie te zdarzenia obsłużone są w jednym miejscu.

>> > 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.

Pamięci dzielonej da się używać także między procesami. Jedyne ograniczenie:
nie można między jednym a drugim przekazywać wprost wskaźników. Czy tak
często jest to problemem... nie wiem. Narzut odpalania występuje także dla
wątków. Nieprzypadkowo istnieją thread-pool, więc mogą i process-pool.
Oczywiście lepiej, jeśli zadania są ze sobą na tyle mało splecione, że można
nie używać pamięci dzielonej, a np. potoków do komunikacji.

>> 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.

W samym Linuksie dodawane są też wywołania systemowe, które nowej
funkcjonalności tak na prawdę nie wprowadzają, tylko zapewniają inny
interfejs do funkcjonalności już istniejących. Np. timerfd_create, signalfd.
Dla frameworka to bez większej różnicy, natomiast jest różnica dla programów
operujących bezpośrednio na tym API.
[Wymienione przeze mnie przykłady są Linux-specific, ale w końcu to też jest
uniksowego API].