Andrzej Jarzabek wrote:

>> 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);
>
> Nie jest to aż tak mało prawdopodobne, żeby dla wielu takich mało
> prawdopodobnych zdarzeń te prawdopodobieństwa nie skumulowały się do
> czegoś zbliżonego do pewności.
>
>>> 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.
>
> Kompilator wyłapie, że obiektu nie ma w zakresie.

Wyolbrzymiasz bardzo mały problem.
A pozbycie się tego małego problemu nie jest pozbawione kosztów.

>>> 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.
>
> No więc z punktu widzenia sensowności organizacji kodu (i co za tym
> idzie niezawodności, maintainability itd.) to mieszanie obsługi
> przywieszonego połączenia z logiką obsługi tego, o czym program jest
> informowany albo o czym informuje za pomocą tego połączenia to tragedia.

Wolę "tragedię" z punktu widzenia organizacji kodu, z jednoczesnym poprawnym
działaniem programu, zamiast kiepskiego działania a za to świetnej
organizacji.

>> 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.
>
> Sensowne protokoły mają zwykle jakiś sposób zaznaczania końca komunikatu.

Rzućmy innym przykładem: IMAP. Zanim serwer skończy obsługę poprzednich
żądań, można już mu wysłać kolejne.

>>> 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.
>
> Być może, ale to "czasami" według mnie w większości odnosi się do
> niewielkich programów.

Jeśli chodzi o użycia sygnałów, to też mam wrażenie że do dużego programu to
się nie przyda.

>>> 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.
>
> Bardzo wiele struktur danych zawiera w sobie wskaźniki. Można oczywiście
> zrobić ich odpowiedniki bez wskaźników, ale to jest dodatkowa
> komplikacja, gorsza wydajność i im więcej tego robisz, tym więcej ci
> wraca problemów, które masz z wątkami.
>
> Pracowałem z takimi systemami, gdzie zamiast wątków robiło się wiele
> procesów operujących na pamięci dzielonej działającej jako prosta baza
> danych, i skalowanie tego było bardzo problematyczne.

Czy po przestawieniu z procesów na wątki stało się mniej problematyczne? Nie
sądzę aby problemy ze skalowaniem wynikały z wyboru procesów zamiast wątków.
Raczej z innych przyczyn.

>> Narzut odpalania występuje także dla wątków.
>
> Znacznie mniejsze.

Masz w pamięci jakieś wyniki pomiarów?

>> Nieprzypadkowo istnieją thread-pool, więc mogą i process-pool.
>
> Można, ale masz dodatkową komplikację opisu każdego zadania i każdego
> rodzaju danych który chcesz przekazać. Na wątkach można po prostu
> przekazać jakiegoś dowolnego funktora.

Na ten temat mam zdanie zgodne z książką "The art of Unix programming":
http://www.catb.org/~esr/writings/taoup/html/ch07s03
.html#id2923889

Zacytuję fragment:
Threads are a fertile source of bugs because they can too easily know too
much about each others' internal states. There is no automatic
encapsulation, as there would be between processes with separate address
spaces that must do explicit IPC to communicate. Thus, threaded programs
suffer from not just ordinary contention problems, but from entire new
categories of timing-dependent bugs that are excruciatingly difficult to
even reproduce, let alone fix.

>> 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].
>
> Drugi problem, o którym miałem napisać, ale zapomniałem, to że te
> interfejsy systemowe są zazwyczaj w C, a to język wyjątkowo kiepsko
> nadający się do wyrażania jakichkolwiek abstrakcji.

Abstrakcja deskryptora plików wyrażona jest świetnie.