🚀 go-pugleaf

> 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