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
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 |