Reinventing the wheel...

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Reinventing the wheel...
Date: 2003-07-21 00:16:04
Message-ID: 20030721001604.GE24784@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-07-21 03:56:51 Re: PostgreSQL 7.3.3 and Intel C compiler
Previous Message Bruce Momjian 2003-07-20 23:24:23 Re: PostgreSQL vs. MySQL