phk at phk
Apr 3, 2006, 4:30 AM
Post #3 of 6
(38 views)
Permalink
|
In message <ujrodzikjcr.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>phk at projects.linpro.no writes:
>> Log:
>> How I wish people would think more ahead when writing libraries like
>> libevent. The entire "implicit event engine" api assumption stinks.
>
>Can you explain what's wrong with it?
Here is the email I just sent to Niels Provos:
>============================================================================
>From: Poul-Henning Kamp <phk at phk.freebsd.dk>
>Subject: libevent, some comments.
>To: provos at citi.umich.edu
>Message-Id: <12019.1144063692 at critter.freebsd.dk>
>Date: Mon, 03 Apr 2006 13:28:12 +0200
>
>
>Please don't take this the wrong way, it is meant to be a constructive
>critisism of libevent.
>
>The background is that I'm writing an application (OSS) which needs
>several event engines in multiple threads and a lot of other
>quasinasty stuff.
>
>My choice was between ISC/s eventlib and your libevent and my initial
>choice where to go with your libevent because of the kqueue support.
>
>Against your libevent counts that the API is quite a mess by now,
>and a far cry from the very stringent and quite fool-proof API
>of the ISC library.
>
>Having gotten somewhat down the road now, I feel that I'm in a position
>to point out a number of improvements to libevent which could make
>it a better proposition for "the default event library".
>
>I hope you'll consider my input.
>
>Poul-Henning
>
>PS: If you're going to be at BSDcan in Ottawa, we can find some time
>and hash the details out if you like.
>
>1: Multi engine support is a mess.
>----------------------------------
>
>The fact that multiple eventengines in the same namespace is bolted
>on later has two unfortunate effects: It messes up the namespace
>with foo_base_bar() functions and it leaves a giant hole for messing
>things up if people are not very very alert.
>
>I would recommend (and be willing to do a lot of the work) that
>a v2 of libevent is created by taking the current sources, making
>the eventbase mandatory throughout and start a new and more systematic
>namespace ("evb_foo()" or "evl_foo()" ?)
>
>A trivial layer of wrapper macros can then implement the current
>ABI, on top of the new one so that nobody will have to rewrite their
>apps unless they want to.
>
>
>2: Timestamp handling
>---------------------
>
>I would recommend is that you adobt some of the time-handling
>facilities from named/ISC's eventlibrary.
>
>Passing a struct timespec instead of a pointer to it may offend old
>C-coders like us, but it makes for much cleaner source code for the
>users:
>
> struct timespec foo;
>
> foo.tv_sec = 1;
> foo.tv_nsec = 0;
> evtimer_mumble(ev, &foo)
>
>vs
>
> evtimer_mumble(ev, TimeSpec(1, 0))
>
>The TimeSpec function looks like this:
>
> struct timespec
> TimeSpec(time_t sec, long nsec)
> {
> struct timespec ts;
>
> ts.tv_sec = sec;
> ts.tv_nsec = nsec;
> return (ts);
> }
>
>And yes, that is legal in all but the most antique compilers.
>
>The advantage of this is that it eliminates the memory management
>for the timestamps out of the users responsibility.
>
>The big advantage comes once you have to start doing math on
>your timestamps:
>
> evtime_mumble(ev, TimeAdd(default_timeout, TimeSpec(10, 0)));
>
>
>
>3: Use CLOCK_MONOTONIC
>----------------------
>
>An eventlibrary should use CLOCK_MONOTONIC to avoid being affected
>by clock-steps from NTPD or similar.
>
>If UTC timing is required, an per event-engine option could switch
>to CLOCK_REALTIME.
>
>
>4: Be carefull with layered facilities
>--------------------------------------
>
>As convenient as http support is, not everybody will need it,
>and for others usurping the http_* and HTTP_* namespace will
>be a major problem in using libevent.
>
>I would propose that the http support be put in a separate
>library or at the very least hidden under a
>
> #ifndef I_DO_NOTWANT_LIBEVENT_HTTP_SUPPORT
>
>so that the namespace polution can be avoided.
>
>--
>Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>phk at FreeBSD.ORG | TCP/IP since RFC 956
>FreeBSD committer | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
|
