On Oct 18, 2006, at 11:49 AM, William Ahern wrote:
On Wed, Oct 18, 2006 at 12:04:11AM -0600, Jason Ish wrote:
I ran across at least one criticism of libevent gaining too much
other
than pure event library:
http://varnish.projects.linpro.no/wiki/EventLibrary
All of these criticisms are partially or wholly invalid.
The DNS and HTTP code is effectively only distributed in the
tarball; it's
not part of the library itself.
Presumably they _will_ be in the library, but I don't see the
problem, either. I'm using libevent in a resource-constrained system,
and typing "p4 delete foo.c" didn't take much of my time. (By the
way, Niels, if you at some point get a 2wire iNID, look for your name
in the user manual. :) On a less-constrained system, you can simply
not use those parts of the library.
I don't understand the issue with struct event_base. Obviously it
evolved,
but I don't understand how the current API is any less useful to a
threaded
application.
I agree with this part - I don't like the "default base" concept
either. My complaint is simple: it's error-prone. If you forget
event_base_set on an event, it's associated with the latest base
created. This will probably work *most* of the time. It'd be much
less confusing if it consistently broke. But I understand libevent
has to keep backward compatibility in mind, and I still haven't
decided what I'd actually like in a threaded event library, so I'm
not proposing any changes, at least right now.
The timestamp issue sounds like, "it doesn't have my particular pet
feature,
so the library is misdesigned". First of all, why is anybody
depending on
timestamps in such a pervasive manner as to want it built into the
libevent
API, knowing or not knowing that the timestamp may or may not be the
particular timestamp the application desires (timestamp on a signal
delivered through a pipe flushed at the end of a loop... how is that
remotely useful for something seriously depending on a timestamp?).
I *have*
written code to give back a fixed timestamp per loop, and maybe it
would be
convenient if I could access libevent's copy, but I wouldn't criticize
libevent for that.
I don't know what their complaint is, but I had to modify libevent's
timer stuff in my copy to achieve two purposes:
1) abrupt clock sets. (Our clock starts at epoch on boot, then gets
set to a real time via SNTP.) There's code in there to handle this,
but I didn't understand/trust it, so I removed it in favor of just
using CLOCK_MONOTONIC. Unfortunately, it's not that portable -
notably, stupid OS X still doesn't support it. Otherwise I'd send in
a patch.
2) recurring timers without drift. I made my copy just take absolute
uptimes, but you could probably achieve most of the same thing by
implementing EV_PERIODIC for timers.
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
