On 15/10/2011 22:51, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> 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);

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.

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

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

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

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

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

Znacznie mniejsze.

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

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

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.