select without a linear search?

Started by
11 comments, last by Kylotan 15 years, 2 months ago
Hey, I got it working. The man page said to do struct epoll_event *events; Thats where it threw me off. I changed it to struct epoll_event events[MAX_PLAYERS]; and that did the trick
Advertisement
Quote:Original post by hplus0603
I agree; the epoll API is better than the select API for certain heavy use cases.

However, have you ever profiled this loop to be a problem? If you start getting more load, what will happen is that any time spent looping over inactive sockets will be time that the other users can add more data to their buffers, which means there will be more active users in the next iteration. The system is self-balancing that way, and under heavy load, the looping time just won't show up on a profile. Meanwhile, why would you optimize the light load case? :-)


This.

It is highly unlikely that the performance of select is really going to be a significant bottleneck.

The two golden rules of optimization:

1) Don't do it.
2) (experts only) Don't do it yet.
Quote:Original post by nethackpro
Hey, I got it working. The man page said to do struct epoll_event *events; Thats where it threw me off. I changed it to struct epoll_event events[MAX_PLAYERS]; and that did the trick


Yes, the example in the man page is obviously very wrong.

Ignore the people who recommend against using epoll() in Linux: the code required to use it over select() or poll() is minimal and it really does scale better than either of those two system calls. If you're handling more than a few hundred simultaneous connections the difference becomes obvious.

One cool trick with epoll() is that you can multiplex the epoll() descriptor with other file descriptors and use it with select(). You might wonder why you'd want to do something like that until you encounter something that wants to take control of your main event loop (OpenSSL, OpenLDAP, or Qt, for instance).

Stephen M. Webb
Professional Free Software Developer

Quote:Original post by Bregma
Ignore the people who recommend against using epoll() in Linux: the code required to use it over select() or poll() is minimal and it really does scale better than either of those two system calls. If you're handling more than a few hundred simultaneous connections the difference becomes obvious.

Yeah, I don't see any reason to use select over epoll now. epoll takes like what? maybe 5 more lines to set up then select? After seeing this
http://monkey.org/~provos/libevent/libevent-benchmark2.jpg
theres no way Ill use select in any programs that I'm expecting a massive amount of connections. Although, it does seem like select would be slightly more efficient with less then 600 or so connections. But I imagine that the difference at that point wouldnt be noticeable enough to bog down any program.
And why someone would tell me not to do it when Ive already stated that I have it set up is beyond me...

Another interesting thing I noticed about the man page, is that it made no mention of adding the listener to kdpfd(the epoll file descriptor created with epoll_create). Luckily I assumed it would have to be. I tested to see what would happen if I didnt, and sure enough, it didnt work

[Edited by - nethackpro on January 22, 2009 11:17:19 AM]
Quote:Original post by nethackpro
And why someone would tell me not to do it when Ive already stated that I have it set up is beyond me...

Well, these are discussion forums, not question/answer forums or tech. support forums. There's an expectation that the 'consumer' of any given thread is not just the original poster but any number of other lurkers or future posters. So sometimes it's worth posting something saying "That may have worked for you, but I still don't recommend it to others". Since select() is more portable and better known than epoll() and no worse a performer in 90% of situations, it's probably best for newbies who might stumble across this thread to be told to use select().

This topic is closed to new replies.

Advertisement