On 26.10.2005., at 17:25, Alvaro Lopez Ortega wrote:
Yeah, I think kqueue is meant to be much faster than poll.. at least
its complexity is O(1) rather than O(n), isn't it?
there are more problems with select/poll
1) at each call of select/poll the user space process passes a list
of fd he is interested on.
The kernel must copy the entire list from user to kernel space (first
O(n) operation).
The kernel must also alloc the space (kernel heap fragmentation
issues etc)
2) when the syscall return the usersspace program must walk the list
to check which fd have returned
second O(n)
3) the kernel itself must walk the list (third O(n)), but it could be
implemented more intelligently offering a backwards interface with
select.
The kqueue spec was written with BSD kernel implementation in mind.
however it depends on how many big N is. The more threads there are
the less connections each thread need to multiplex.
So if there is a good threading implementation (nptl) on a system
without kqueue one could tweak the parameters to having nthreads
a small fraction of maxconnections. However I don't know practically
the relative overheads of select vs. threading
any ideas?
-- marko
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
