benchmark it against a different loop.
consider:
nready = poll (ufds, num_fds, 10);
for (count = 0; count < num_fds; count++)
{
if (!ufds[count].revents) continue;
(*entry_tab[count]->callback)(entry_tab[count], ufds[count].revents);
if (--nready == 0)
break;
}
look at the benefits:
1) the loop is much faster (just an increment of a register, and
a single memory test, that goes in order)
2) you aren't thrashing the cache, following a linked list of
thousands of elements that are probably allocated all over memory
3) you don't have to use a linux-specific system call.
4) overall memory use should be similar (no pesky next pointer,
or previous either).
another place you might get a big win is in allocating a minimal entry
structure (fd, events, callback, data ptr), in a block of the number of
file descriptors. adding or deleting an entry involves copying only 4
fields, and now the entries are all contiguous in memory, which means
scanning the entry list is (slightly) faster. This way you won't fragment
memory.
another note... in real use the list version might get noticeably slower
if the event structures are fragmented. The benchmark was probably with
them allocated in order, no?
> To avoid scanning the list, I propose a poll2() syscall which looks
> like:
<snip>
sending user data into the kernel and back seems like a hateful way to do
things... This system call might be marginally faster than the loop above,
in the case where few file descriptors are active... but on the average,
it may end up losing (have to copy every active file structure).
since we are now talking about user space... let's take it offline (reply
directly to me, not to the list)
-gordo