> > Ale my nie widzimy tych socketów, bo one są ukryte w tych
> > bibliotekach.
>
> To jakieś strasznie opakowane te biblioteki, że nie pozwalają dobrać
> się do źródłowego socketa.

Jest gorzej. To nie muszą być sockety. Np. system QNX ma fajny mechanizm komunikacji
IPC, który istnieje poza przestrzenią deskryptorów plików. A ktoś inny będzie się
komunikował przez pamięć dzieloną. Itd. Więc nawet gdybyś miał dostęp do bebechów, to
i tak nie zapiąłbyś wszystkiego razem jednym selectem.

No i nie możemy zakładać, że socket jest jeden, albo że ciągle ten sam, itd. Straszne
komplikacje.

> A co mówi dokumentacja tych bibliotek?

To, co napisałem. Że wymienione funkcje robią robotę i wychodzą albo od razu
wychodzą.

> Chyba ich autorzy nie zakładają,
> że ktoś będzie busy loop tworzył czekając na tweeta?

Nie musi być busy loop. Bo możemy też założyć, że w każdej bibliotece jest dodatkowa
funkcja wait_for_work(). Albo że te funkcje mają dodatkowy argument, żeby czekać. Tak
jest w YAMI4. Wtedy pętla użytkownika nie musi być busy - po prostu blokuje się, jak
nie ma nic do roboty.

Ale mamy 3 takie funkcje. I co teraz?

> W
> takiej sytuacji wystarczy odczekać chwilę

Dalej kiepsko, bo chcemy bez opóźnień przetwarzać zadania, jeśli są dostępne, i nie
marnować prądu, jeśli nie są.

> Ale to tylko jeśli biblioteki faktycznie nie udostępniają
> jakichkolwiek mechanizmów sygnalizacji swoich potrzeb.

Dobry trop.
To w jaki sposób chciałbyś być poinformowany, że biblioteka ma potrzebę?

Przypominam, że mamy 3 biblioteki. Przyjmijmy wersję idealną, że wszystkie 3 będą
mieć ten mechanizm. Jaki?

--
Maciej Sobczak * http://www.inspirel.com