Administrace komentářů

Smarja, ved su aj ine moznosti ako timeout nulovy a nekonecny! Ak potrebujem kazdu sekundu (dosadte si konstantu podla potreby) kontrolovat obrazok z kamery, tak nastavim sekundovy timeout (prip. sekunda minus epsilon, kedze to volanie selectu nieco trva a spracovanie obrazku z kamery tiez). Ked sa mi select vrati, tak sa pozriem ci preto, ze nieco prislo na nejaky filedescriptor alebo preto, ze expiroval. Ak expiroval, tak spracujem kameru a a zavolam select znova. Ak neexpiroval, tak osetrim filedescriptory, nastavim novy timeout na ten, s ktorym sa mi vratil select (prip. este minus epsilon) a zavolam ho znova.

Takze jednoduche je to dostatocne. Zataz procesora nie je vyssia ako nutna, pretoze ho vyuzivam skutocne len vtedy, ked pridu data alebo ak potrebujem spracovat kameru. Nebudim sa zo selectu castejsie ako musim. Ak by som sa rozdelil do dvoch vlaken, tak sice mam nekonecny timeout na selecte, ale to druhe vlakno aj tak kazdu sekundu pouzije CPU na ovladanie kamery. Takze som neusetril nic a prepinanie vlaken tiez nieco stoji. A snazim sa ako mozem, ale spozdenie dat nedokazem najst. Kde by malo byt?

BSD-like Unixe, nenastavuje zvysny cas v timeoute selectu, takze na BSD si treba ukladat systemovy cas pred volanim selectu a porovnavat ho so systemovym casom po navrate z neho.

Pre sietovu cast velkeho skolskeho projektu som programoval pred asi 4 rokmi nieco velmi podobne. Drzat mnozstvo otvorenych TCP spojeni, cez ktore pritekaju a odetkaju data. Ziadne spojenie nesmelo trvat dlhsie ako definovany cas (ochrana pred DOSom), ak pretiahalo, tak bolo ukoncene. A stale som musel byt schopny reagovat aj na "signaly" zo zvysnej casti programu = ostatnych vlaken (sifrovacich, hlavneho ovladacieho atd.). V zadani projektu bola vyzadovana prenositelnost minimalne na Linux, Mac, Win. Takze na POSIXove signaly so mmohol zabudnut (co ja by som dal za pselect()). Riesil som to vytvorenim TCP spojenia, ktoreho oba konce drzal program samotny a jeho citaci koniec bol zaraadeni do mnoziny filedescriptorov pre select. Ked chcel niekto zobudit cakajuce sietove vlakno, tak zapisal spravu do konca tohoto spojenia urceneho pre zapis (to bolo dostupne vsetkym). Tym sa prerusil select a standardnou cestou sa zistilo, ze nejaky vlaknovy kolega po mne nieco chce (napriklad restart, alebo zmena maximalneho poctu spojeni, zmena timeoutu pre spojenia a pod.). Systemovy cas expirovania kazdejo spojenia bol vo utriedenej fronte a vzdy rozdiel medzi jej prvym prvokom a systemovym casom urcoval timeout pre select. Do fronty sa pridavalo iba na koniec, odoberalo zo zaciatku a nemusela sa v kazdom kroku prepocitavat. V pripade spojenia, ktore stihlo poslat vsetky data este pred vyexpirovanim je nutne najst zaznam uprostred fronty - moze sa spravit kruhova v poli a binarnym vyhladavanim znizit tuto zlozitost na logaritmicku. Alebo mat vyhladaciu tabulku indexovanu cislom descriptoru ukazujucu do fronty a mat to konstantne.

Testovane to bolo v 24h v skolskom labe s desiatkami pocitacov, kde kazdy komunikoval s kazdym a kazdy drzal desiatky otvorenych spojenia a zataz sietoveho vlakna zanedbatelna oproti sifrovacim vlaknam. Programuje sa to trocha zlozitejsie ako Hello world, ale nez si nechat v systeme zit a prepinat 100 vlaken (nech aj v poole), kde kazde obsluhuje jedno spojeni...