Administrace komentářů

Tak si tvořím ten event loop, protože jsem nic nenašel. Studoval jsem poll a epoll a nejsem z toho nadšený.

poll

poll() mi nabízí: přidání descriptoru v O(1), když je místo v poli, O(N), když bude potřeba realokovat. Pak O(N) kopií do kernelu a O(N) kopií z kernelu při volání poll(), a odebrání deskriptoru O(1). Budu muset udržovat 2 pole, jedno struct pollfd[N] a druhé pole ukazatelů na struktury, kde bude uložen pointer na callback a index, kde se fd nachází (aby odebrání bylo O(1)). Deskriptorů nebude hodně (v řádu stovek), ale budou se často měnit. Když bude jeden mít hodnotu 5, druhý 300 a třetí 60000, tak kvůli tomu nechci alokovat (dvě) pole s 60000 prvky, aby to mohlo být O(1), takže potřebuju ten index. Při odebrání prostě na místo přesunu poslední prvek. Každý thread bude mít event loop, takže by to ve výsledku bylo moc paměti. Stačí, že už kernel obsahuje mapování 1:1 na deskriptory, aby to mohlo být O(1). Takže souhrn:

• Přidání: O(1), 0 syscallů, zřídka O(N) a nějaký syscall na realokaci
• Odebrání: O(1), 0 syscallů
• Poll: O(2*N) + něco dalšího v kernelu, 1 syscall

epoll

epoll() mi nabízí: stačila by mi struktura, kterou bude udržovat uživatel, ta bude obsahovat callback a deskriptor. Descriptor je potřeba totiž znát k odebrání, při použití obyčejného pollu mu ho můžu předat při volání callbacku, s epollem to možné není, protože ho z navráceného seznamu z kernelu neznám. Každé přidání a odebrání bude vyžadovat jeden syscall. Pollování bude taky jeden syscall a O(M) kopií z kernelu, kde M je velikost epoll bufferu, která se může lišit od počtu descriptorů N. Přidání a odebrání netuším, jestli O(1), nebo jestli má nějakou mapu s O(log(N)) ... Další problém s odebráním je, že musím v O(M) projít lineárně celý seznam "připravených" deskriptů, jestli tam není deskriptor už připraven, abych se ho později nestažil zpracovat. Pokud bych měl buffer stejně velký jako počet deskriptů (kdyby byl věčně plný od epollu(), tak bych ho zvětšoval M až do N), tak by odebrání mohlo být Nějaké O(N * log(N)) + syscall (jestli to má kernel jako mapu).

Co jsem tak koukal na různé knihovny (libuv, libevent), tak to moc neřeší a alokují si pole, které je velké alespoň jako maximální deskripto, který můžete přidat. Některé mají fixní limit na 1024. To je třeba na mém systému výchozí hodnota pro proces, ale jde zvětšit až na 64k pro uživatelský proces a možná i víc pro roota.

No moje otázka je, co s tím. Jak to řešit. Cílem je taky co nejméně alokací dělané knihovnou, alokaci by si měl nejlépe řešit uživatel knihovny, ale úplně to nepůjde. Epoll potřebuje nějaký buffer pro výstup a poll i pro vstup, takže sem tam budu muset alokaci provést. Kdybych nechtěl procházet buffer epollu při odebrání deskriptoru, mohl bych třeba alokovat ještě další strukturu a tam teprve ukládat informace s callbackem od uživatele a poznamenat si tam "odebráno", a teprve, až se k ní dostanu, tak ji uvolnit či připravit k dalšímu použití, ale to je další alokace na deskriptor.