[Development] epoll event dispatcher

[Oswald Buddenhagen]

On Fri, Aug 09, 2013 at 08:48:12AM -0700, Thiago Macieira wrote:
> On sexta-feira, 9 de agosto de 2013 10:39:33, Oswald Buddenhagen wrote:
> > On Thu, Aug 08, 2013 at 09:13:42AM -0700, Thiago Macieira wrote:
> > > 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.
> 
> Right, so you're proposing we allocate memory in Qt and run the event loop 
> more often to do those tasks. That sounds like more overhead to me. I'm not 
> convinced that any benefit of the kernel side would be bigger than the overhead 
> we're talking about adding here.
> 
ehm, no. that "event queue" could be a simple semi-static vector of
pointers. no allocation in the usual case.

> By the way, QSocketNotifier could be more efficient too if its
> "setEnabled" could be directly pushed to the dispatcher, without fully
> registering or unregistering the notifier.
> 
now, that sounds like it could work. at least it would avoid the
QSockNot (de-)allocation and list iteration every time a socket notifier
is toggled. ;)

> > 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).
> 
> Less data transferred, but bigger overhead on the kernel side since it needs 
> to iterate on each bit of the transferred data.
> 
that's less expensive than iterating a big array of pollfds. in
particular when bit search operations are used.

> I've talked to kernel developers and they tell me that epoll is not meant for 
> generic, graphical user applications with a handful of file descriptors. It's 
> meant for large server applications with hundreds of file descriptors or more.
> 
correct.
conversely, the overhead of *either* approach is negligible for apps
with only a few active fds.

> > was even the timer handling finally fixed, or is it still an unsorted
> > linear list?
> 
> It's been a sorted list for the past 10 years.
> 
oh, indeed.
it's a _sorted_ vector-style list, which uses linear search and
insertion-by-memmove. sounds much better then.
i'll note that the qml guys identified that as a major bottleneck a few
years ago and wrote their own timer code.