Thread: Reinventing the wheel...

While talking with someone about code portability and building in a
scalable persistent connection manager into PostgreSQL, someone
pointed me to libevent's existence .  In the past, I'd always
rewritten this wrapper by hand every time I needed to do handle
providing a generic kqueue/poll/select.  It looks Niels has done this
correctly and in a more general/useful way.  Because this library
provides a much more general interface that makes use of an OSes
optimal FD event system call, is BSD licensed (standard 3-4 clause
license), and should be very portable, would would anyone object if I
integrated this into the tree?  The savings across the entire tree
could be sizable, though I have no numbers to back this up other than
the graphs that are presented.

http://www.monkey.org/~provos/libevent/libevent-benchmark.jpg
http://www.monkey.org/~provos/libevent/libevent-benchmark2.jpg

To prevent lib naming collisions with machines that have libevent
installed, I plan on renaming all of the functions from event_* to
pgevent_*.  libevent also has the appropriate autoconf goo to make
detection of the right library pretty seamless.  It even supports the
new Linux interface epoll.

Tom, I know you just replaced a bunch of select() calls with poll().
Would you mind if I went through and patched things to use libevent's
abstraction layer?

Once this is done, then I'll go back and use libevent for the
persistent connections goo.  -sc

-- 
Sean Chittenden

Sean Chittenden <sean@chittenden.org> writes:
> ... Because this library
> provides a much more general interface that makes use of an OSes
> optimal FD event system call, is BSD licensed (standard 3-4 clause
> license), and should be very portable, would would anyone object if I
> integrated this into the tree?

AFAICS this library is presuming facts not in evidence, namely that
we care about watching thousands of connections at once.  In the
current Postgres structure we have absolutely no use for it.

You're welcome to base your multiconnection hack on it, but I won't
vote for integrating any of that work until I see proof that it's
actually a win (which, quite honestly, I do not expect to see).
        regards, tom lane

Sean Chittenden wrote:
> To prevent lib naming collisions with machines that have libevent
> installed, I plan on renaming all of the functions from event_* to
> pgevent_*.  libevent also has the appropriate autoconf goo to make
> detection of the right library pretty seamless.  It even supports the
> new Linux interface epoll.

Please don't. For those of us using an OS that has libevent as standard,
this is just pollution and perhaps you should instead look to carry the
portable code in the distribution and build/link to it if the normal
libevent is not available (configure will happily check for you).

Peter