-
X-Received: by 2002:ac8:35fd:: with SMTP id l58mr9735339qtb.324.1591898434817; Thu,
11 Jun 2020 11:00:34 -0700 (PDT)
X-Received: by 2002:ac8:35fd:: with SMTP id l58mr9735339qtb.324.1591898434817; Thu,
11 Jun 2020 11:00:34 -0700 (PDT)
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
e.net!feeder.erje.net!feeder5.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenete
xpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca
1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.g
oogle.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: pl.comp.programming
Date: Thu, 11 Jun 2020 11:00:34 -0700 (PDT)
In-Reply-To: <20200611103732.69e48f11@mateusz>
Complaints-To: g...@g...com
Injection-Info: google-groups.googlegroups.com; posting-host=213.108.152.51;
posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
NNTP-Posting-Host: 213.108.152.51
References: <5...@g...com>
<20200609094640.04ee0ae2@mateusz>
<a...@g...com>
<20200610105625.30b3dad0@mateusz>
<e...@g...com>
<20200611103732.69e48f11@mateusz>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9...@g...com>
Subject: Re: Integracja bibliotek event-based
From: Maciej Sobczak <s...@g...com>
Injection-Date: Thu, 11 Jun 2020 18:00:35 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 118
Xref: news-archive.icm.edu.pl pl.comp.programming:214992
[ ukryj nagłówki ]
> Trzymajmy się założeń: była mowa o bibliotece "do http", innej "do
> tweetera" i trzeciej "baza danych".
Nie. Była mowa o integracji kilku bibliotek event-based.
Przykłady dot. HTTP, bazy danych i Twittera to były *przykłady* do zobrazowania
problemu a nie konkretne zadania do rozwiązania.
Właściwym problemem jest integracja bibliotek narzucających jakiś idiom czy wzorzec
ich obsługi.
> Każda z nich raczej (?) opiera się
> na socketach.
Nie. W szczególności biblioteka do baz danych automatycznie dobierze metodę
komunikacji zależnie od tego, gdzie jest baza. W szczególności, jeśli baza jest na
tym samym komputerze, to istnieją sprawniejsze metody komunikacji, niż sockety.
Wyobraź sobie dla jeszcze szerszego spektrum, że jedna z tych bibliotek to zwykłe
GUI, gdzie "gotowość" to event w kolejce, bo użytkownik coś kliknął.
Czyli tu nie chodzi o sockety. Tu chodzi o integrację bibliotek.
> > No i nie możemy zakładać, że socket jest jeden, albo że ciągle ten
> > sam, itd. Straszne komplikacje.
>
> Jeśli jest ten sam to komplikacji nie ma - jeśli się urywa to
> biblioteka zwraca błąd i trzeba zainicjalizować na nowo. Jeśli
> natomiast socket się tworzy nowy przy każdym zawołaniu (np. sprawdzanie
> tweetów via nową sesję ssl za każdym razem), to każde sprawdzenia
> powinno być regularnie wywoływane przez program.
Nie na temat, ale dalej źle. Przykładowo, YAMI4 może mieć tysiące socketów. Pomijając
drobny fakt, że select() nie nadaje się do obsługi tysięcy socketów, biblioteka
stosuje algorytmy control-flow decydujące o tym, który kanał w ogóle albo w danym
momencie zasługuje na obsługę. Czyli z faktu, że wśród tysięcy socketów kilkaset ma
dane gotowe do odczytu wcale nie wynika, że to jest stan gotowości do wykonania
zadania, bo akurat te sockety z gotowymi danymi nie muszą mieć "zielonego światła" na
ruch komunikatów i może się okazać, że wtedy nadal jest "idle". O tym decyduje
biblioteka.
Dlatego nie możesz się nastawiać na to, że będziesz sobie sam obserwował te sockety,
bo i tak nie masz kontekstu do pełnej oceny sytuacji.
Co więcej, jest kompletnie bez sensu, żebyś duplikował ciężką pracę, którą biblioteka
i tak robi w środku.
> > Przypominam, że mamy 3 biblioteki. Przyjmijmy wersję idealną, że
> > wszystkie 3 będą mieć ten mechanizm. Jaki?
>
> Idealnie? No to chcę sam obsługiwać kanał danych (socket, IPC,
> whatever), a bibliotekę będę wołał tylko po to, żeby te dane
> obrobić/przetłumaczyć.
Już ustaliliśmy (powyżej), że nie.
> Ostatnia opcja: niech biblioteka da jakiś
> swój blokujący "wait_for_event()", sama niech blokuje w sposób
> eko-mądry i zależny od implementacji, a ja sobie ją wywołam w osobnym
> wątku. 3 biblioteki = 3 wątki, da się przeżyć.
Świetnie.
Doszedłeś w ten sposób do wniosku, że do obsługi *kilku* bibliotek event-based
potrzebne są wątki. Albo wyjdą z biblioteki albo do niej wejdą. Ale będą potrzebne.
Głębsza analiza wygląda tak:
Pojęcie "idle" lub "nie ma zadania", itp. to pojęcia *lokalne*, zrozumiałe tylko w
obrębie jednej biblioteki. Tzn. w bibliotece GUI to pojęcie oznacza, że user nic nie
kliknął, w bibliotece komunikacyjnej że nie ma komunikatu, w bibliotece do baz danych
że nie ma jeszcze odpowiedzi na wcześniejsze zapytanie, itd. To są stany *lokalne*.
Jeżeli program jest w całości oparty o rytm pracy *jednej* biblioteki (tak jak w
prostym GUI opartym o zdarzenia z okna), to ten lokalny koncept jest też globalny,
czyli dotyczy całego programu. Wtedy nie są potrzebne ani wątki, ani muteksy.
Ale jeśli mamy kilka takich bibliotek, każda ze swoim własnym konceptem "idle", to
ich integracja jest problemem, bo globalnie "idle" oznacza, że *nikt* nie ma nic do
roboty a tego stanu nie da się uwspólnić w jednym wątku, bez ciężkich kompromisów
typu kręcenie się w pętli z odpytywaniem (nawet z jakimś mniej lub bardziej
przemyślanym opóźnieniem).
Dlatego albo:
1. pozwolimy tym bibliotekom niezależnie informować o swoim bieżącym stanie przez
callbacki wychodzące z tych bibliotek (w takim callbacku można np. odetkać główną
pętlę czekającą na jakiejś fladze stopu) (co wymaga istnienia wątków w tych
bibliotekach), albo
2. zrobimy sobie osobne wątki do kręcenia blokującymi pętlami dla każdej biblioteki
osobno, albo
3. w ogóle schowamy ten koncept "idle" razem z pętlami zdarzeń i pozwolimy
bibliotekom kręcić swoimi zdarzeniami samodzielnie (z własnych wątków).
Tak czy inaczej mamy wątki. I ich konsekwencje.
Ktoś ma pomysł na rozwiązanie tego problemu bez wątków?
--
Maciej Sobczak * http://www.inspirel.com
Następne wpisy z tego wątku
- 11.06.20 21:58 Mateusz Viste
- 12.06.20 20:55 Maciej Sobczak
- 13.06.20 09:33 Mateusz Viste
- 13.06.20 21:52 Maciej Sobczak
- 14.06.20 13:55 Mateusz Viste
- 14.06.20 20:52 Maciej Sobczak
Najnowsze wątki z tej grupy
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
- Ideologia Polskiego Programisty wer.3
Najnowsze wątki
- 2024-04-27 DC blocker i buczące toroidy
- 2024-04-26 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-04-26 Berlin => IT Network Engineer <=
- 2024-04-26 Warszawa => Starszy inżynier oprogramowania (Rust) <=
- 2024-04-26 Warszawa => Senior PHP Developer (Symfony) <=
- 2024-04-26 Białystok => Business Development Manager - obszar bezpieczeństwa IT
- 2024-04-26 Bieruń => Administrator i wdrożeniowiec Lotus Notes/Domino <=
- 2024-04-26 Warszawa => Product Owner/ Product Manager <=
- 2024-04-26 Warszawa => International freight forwarder <=
- 2024-04-26 Gdańsk => Senior Software Engineer PHP (BillPro) Kontraktor <=
- 2024-04-26 Jak się płaci CIT ?
- 2024-04-26 steve balmer o iphonie w 2007
- 2024-04-25 Wrocław => Java Developer <=
- 2024-04-25 Kraków => AI Specialist <=
- 2024-04-25 Berlin => Solution Architect (secure communication and IoT solutions)