[Development] epoll event dispatcher

[Thiago Macieira]

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.

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.

> > 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).

Less data transferred, but bigger overhead on the kernel side since it needs 
to iterate on each bit of the transferred 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'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.

If anything, we'd need to change our interface in QSocketNotifier to benefit 
from the edge trigger. We toggle our write notifications all the time because 
we need the edge, not the level.

No, epoll makes no sense until we fix our code first.

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

Agreed, after fixing those *first*.

> 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?

It's been a sorted list for the past 10 years.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130809/f8689182/attachment.sig>