[Development] epoll event dispatcher

[Oswald Buddenhagen]

On Thu, Aug 08, 2013 at 09:13:42AM -0700, Thiago Macieira wrote:
> On quinta-feira, 8 de agosto de 2013 17:46:05, Oswald Buddenhagen wrote:
> > would it be possible to optimize it behind the scenes (e.g.,
> > propagate the toggling to the kernel only upon entering the event
> > loop)?
> 
> Yes, that would be ideal. That would require iterating over all socket
> notifiers we have on this event dispatcher, to determine which ones
> have changed since.
>
not necessarily. it would be possible to post some kind of events to the
dispatcher itself, so it would check only the notifiers that had any
toggling going on. the relative efficiency would grow inversely to the
percentage of notifiers that were toggled during one event loop
iteration.

> Then we'd have to do a series of epoll_ctl calls to toggle before
> doing our sleep with epoll_wait.
> 
> I'd rather not do a flurry of syscalls before epoll_wait. That's
> wasteful. 
>
it would be wasteful if many notifiers would actually have to be
toggled in every iteration, i.e., if the mentioned optimization would be
mostly ineffective.

> Instead, I'd rather have a syscall that sets the file descriptor state
> and sleeps in one single syscall.
> 
> That's called poll(2).
> 
just as is select(), which is a lot cheaper in the common case (less
data transferred to/from the kernel, easier to interpret the data).
otoh, both of these interfaces require the kernel to a) perform the
polling and b) in case of no activity, set up (and later tear down) the
internal watchers. this is exactly why epoll() was introduced: the
kernel's internal event queue is directly pushed to user space without
polling, mapping and setup/teardown. this vastly reduces overhead when
userspace behaves sanely.

i don't think it makes sense to judge either approach without seeing the
*actual* use patterns, especially after fixing the obvious braindamages.

another consideration is that it is utterly unlikely that the event
loop's ability to efficiently process hundreds of sockets is of any
relevance to qt.
was even the timer handling finally fixed, or is it still an unsorted
linear list?