> 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