🚀 go-pugleaf

On 05/11/2020 13:43, michal.lyszczek@bofc.pl wrote:
> Jak 1 z kolokwium to brzmi "To ogromna aplikacja" ;-)

To raczej problem z okolic "w ksiąze do programowani jest taki przykłąd 
na 3 linijki i działa", a potem masz bazę kodu na ~500MB (nie 
przesadzam) i zastanawiasz się jaki idiota wymyślił globalny handler 
który ma obsługiwać setki równoległych i kompletnie niezależnych części 
tej aplikacji.

> Dodatkowo, zmierzyłeś
> że problem z wydajnością jest spowodowany przez select/poll?

Apliakcja wykonuje miliony ::read( *foo, 4 );. Ogólnie wykonuje bardzo 
dużo małych read na namedpipe, bezustannie komunikujac się z inną 
apliakcją (inny proces). Przypuszczam że każdy ::read to switch 
kontekstu do kernela, albo przynajmniej jakieś cieżkie operacje na 
granicy kernel/user space.

> Jak masz tam
> raptem kilka deskryptorów, to ciężko mi uwierzyć żeby to miało taki narzut
> na wydajność i problem jest zapewne gdzie indziej. To, albo optymalizujesz
> program na siłę.

Nie, zostało to dokładnie rozpracowane. ::read jest znaczaco szybszy niż 
::poll->::read. Nawet w syntetycznym przykładzie da się to zobaczyć.

> Jak bardzo chcesz mieć nieblokujący read(2) oraz nie używać polla to możesz
> zawsze ustawić przy pomocy fcntl(2) ustawić flagę O_NONBLOCK, i przy każdym
> read(2) gdy nie będzie danych dostaniesz zwrotkę -1 oraz errno na EAGAIN.

Jesli teraz zawolam ::read ponownie i tak w kółko to właśnie przerobiłem 
komputer na grzejnik. A jak wstawie usleep... no własnie...