Administrace komentářů

Takže nakonec to dopadlo takto:

struct poll_handler
{
  uintptr_t magic_value_1;
  uintptr_t magic_value_2;
};

Kde

magic_value_1 = (((uintptr_t)fd & 0xffff0000u) << 48)
               | (uintptr_t)callback
               | (uintptr_t)flags;

magic_value_2 =  (((uintptr_t)fd & 0xffffu) << 48)
               | (uintptr_t)userdata;

   nebo (podle nastavení flags)

magic_value_2 =  next_poll_handler;

Tím mám 16 bytů na strukturu.

Vejdou se tam uživatelská data (musí být platný ukazatel, tj. má 47 spodních bitů (pointery s bitem 47 (který se pak kopíruje i do zbytku do 63) jsou rezervovány pro kernel), zarovnání je nedůležité, spodní bity v userdata nepoužiji. Nahoře mám 17 bitů, použiju jen 16 a tam kydnu tam spodních 16 bitů deskriptoru.

Pak callback, kompilátor funkce zarovnává na 16, a opět max je 47 bitů. Takže horních 16 bitů pro horních 16 bitů deskriptoru, spodní 4 bity na flagy. Flag zatím užiju jeden, 'removed'. Ten nastavím, když uživatel odstraní deskriptor, zároveň se přepíšou userdata na pointer na další odstraněnou položku ... jak tedy uživatel odstraňuje, dělám linked list odstraněných položek.

Obsluhování bufferu je tak, že procházím položky. Když je bit 'removed' nastaven, položku přeskočím, když ne, zavolám callback a jdu na další. Až dojedu na konec, tak struktury nalinkuju do seznamu s 'volnými' handlery. Ty neuvolňuju a nechávám je pro další použití při přidání deskriptoru.

No ... a stejně se mi to nelíbí, je to hrozná splácanina, jestli to za těch ušetřených 8 bytů, o které by struktura narostla, stojí. Ale asi by byla moc hezká:

struct poll_handler
{
  poll_callback cb;
  void *userdata_or_next;
  int fd;
  int flags;
};

Při 65k descriptorech to je půl megabajtu.

Jinak koukal jsem na zdroják kernelu a epoll uchovává přidané položky v obrovských strukturách, nalinkované v červenočerném stromu a pak ještě linkované pomocí ready-stavu a pak ještě linkované jánevímčím. Přidání/odebrání/modifikace je tedy O(log N) a stojí syscall.