Hi all,
been reading the select(2) man pages and it mentions poll(2)

being more efficient in most cases. this makes it obvious to

discard the use of select(2) in writing new servers.
i've come across some performance benchmarks which is trying

to use kqueue(2).
the question is, which one is more useful when writing new servers?

kqueue or poll?
--

garnet:jasmin:beryllium:gluon

90-12264

90-B

yes. poll is the way better API, easier to use, easier kernel-side, 
using kqueue directly is painful. I'd recommend libevent if you really

want to go that route.

That said, kqueue really only pays out when you have _lots_ of 
programming w/ libevent is convenient at times, the decision poll vs

libevent should not be made based on performance considerations,

exception beeing the above massive concurrent connection case.
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

I spent a lot of time doing libevent stuff for a work project the last

few weeks and I am in love with the API.  One negative is the poor

documentation; especially the buffered events docs are inadequate.
Yes, I read the source :-)  but it would have been a little less painful

to have a slightly better man page and some standalone examples.
Negatives aside once you figure it out it allows one to write code that

doesn't require threading and other complexity inducing stuff.  Yay

finite state machines!

Yay, I too fell in love with it and it's various API's despite the lack

of documentation for most of them, header help understanding how things

work but I wasted quite some time on bufferevents ;-)
Gilles
--

Gilles Chehade

http://www.poolp.org/

The documentation has actually become much better over time:
 http://www.monkey.org/~provos/libevent/doxygen-1.4.3/
However, I'd be happy to see any patches to improve the documentation.
Thanks,

 Niels.

I found the doxygen docs far less useful than the man page.
On Apr 23, 2008, at 10:31 PM, "Niels Provos" <provos@citi.umich.edu>

poll is more portable, while kqueue should be more performant (at

least, that's why it was invented). If your app only needs to run on

OpenBSD, NetBSD and FreeBSD, you're just fine with kqueue, otherwise

use poll. Generally, I think it's better to use poll and sacrifice that

unnoticable performance gain.
--

Jonathan

As usual, depends what you want to do.
poll() and select() give you control over file descriptors. kqueue

encompasses more events. It's not especially faster, it just leads to

simpler code in case you need the supplementary events.
If all you need to do is watch over a set of file descriptors, poll

and select are the simplest ones to use... and the most portable.
In many, many cases, poll() is better. The only case where select comes

close is when you want to watch over most of your file descriptors (because

you access less memory in such a case).
And then, you should profile. I'm not even sure it makes a difference.
Most of the places in the system where we have select() are legacies: it

it's not broken, don't fix it.

Marc, Henning,
thank you for the insight.
--

garnet:jasmin:beryllium:gluon

90-12264

90-B

--

garnet:jasmin:beryllium:gluon

90-12264

90-B

On Sat, 19 Apr 2008 13:27:34 +0800
The more useful is event(3).
Eric.

Hi Eric,
i've been looking also at libevent and libev, both of which are excellent

libraries. however, i'm more interested in simpler system calls rather

than the libraries.
thank you for pointing this out. interesting that openbsd has libevent
--

garnet:jasmin:beryllium:gluon

90-12264

90-B

select requires that you set up a bit array correctly.  but often

people just use a fd_set, and cause a variety of strange buffer

overflow cases as soon as their fd's happen to be greater than the bit

size of the fd_set.
the kernel has to iterate over these bit arrays a few times.
for everyone involved, poll is just plain cheaper.
finally, go look at the latest commit to lib/libc/net/res_send.c to
use poll.  it is easier to use -- the behaviours are less surprising.

it is also much more portable.  everyone has select and poll, and

quite honestly poll() is a better select(), even if it came out of

AT&T.

thank you, Theo.
poll it is. again, many thanks.
--

garnet:jasmin:beryllium:gluon

90-12264

90-B