Reinventing the wheel... - Mailing list pgsql-hackers

From Sean Chittenden
Subject Reinventing the wheel...
Date
Msg-id 20030721001604.GE24784@perrin.int.nxad.com
Whole thread Raw
Responses Re: Reinventing the wheel...  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Error messages --- now that we've got it, do you like
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL 7.3.3 and Intel C compiler