[Development] epoll event dispatcher

[Cyril Oblikov]

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

Sure this is mostly for server-side applications. For now Qt is used
for servers very seldom, but you can google some examples. This is
also because QtNetwork is inefficient for such purposes.

>From the other side Qt is going mobile now, and a really huge part of
mobile apps use client/server model. It's a great plus for developer
to share the same code on both server and client (just like browser's
javascript and server-side node.js). So maybe improving QtNetwork
(especially using epoll instead of poll/select) is worth it...

2013/8/9 Oswald Buddenhagen <oswald.buddenhagen at digia.com>:
> 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?
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development