Re: nsock epoll() reactor?

[Fyodor <fyodor () insecure org>]

On Wed, Nov 07, 2007 at 12:29:51AM +0100, majek04 wrote:
> Btw. It seems that in some corner cases nmap's nsock core is faster
> than libevent :)
> http://majek4.blogspot.com/2007/11/trinity-choice-nsock-over-libevent.html

Yeah, I saw that post previously and was glad to see Nsock perform so well!

> Nsock is based on good old select()  (nsock_core.cc, line 174)
> Maybe it's time to move to some newer and faster technologies
> like epoll()?
>
> I think that stealing the code from libevent/epoll.c could
> be good idea for start. (except for BSD + advertising license)

Sure, if you want to make that change and test it, I'd love to see if
it helps or not in any practical cases.  Obviously we will still need
to support select for the many systems which don't have epoll, but the
configure script could decide what to use on each system.

You probably won't have to use any material amount of code from
libevent, since I think most of the work is straighforward use of the
API or specific to nsock data structures.

> Also lighttpd has some interesting reactors
> (lighttpd/src/fdevent_linux_sysepoll.c).
>
> What do you guys think?

It was something I considered back when writing Nsock, but select
didn't seem to be a big performance bottleneck.  Remember that Nmap
rarely has more than a few dozen sockets open at once.  But if you
write code to add newer APIs and you can show that it makes a material
difference in some cases, I'd be happy to put it in after the upcoming
stable Nmap release.

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org