🚀 go-pugleaf

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