commit 88bb40d8f87077e2f954b6de779ac52c637c69ec Author: Nick Mathewson nickm@torproject.org Date: Fri Mar 25 15:32:45 2011 -0400
Clean up a comment-conversation about bad libevent version/method combos --- src/common/compat_libevent.c | 17 ++++++----------- 1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/src/common/compat_libevent.c b/src/common/compat_libevent.c index 3efc56d..3ad9be1 100644 --- a/src/common/compat_libevent.c +++ b/src/common/compat_libevent.c @@ -330,17 +330,12 @@ tor_check_libevent_version(const char *m, int server,
version = tor_get_libevent_version(&v);
- /* XXX Would it be worthwhile disabling the methods that we know - * are buggy, rather than just warning about them and then proceeding - * to use them? If so, we should probably not wrap this whole thing - * in HAVE_EVENT_GET_VERSION and HAVE_EVENT_GET_METHOD. -RD */ - /* XXXX The problem is that it's not trivial to get libevent to change it's - * method once it's initialized, and it's not trivial to tell what method it - * will use without initializing it. I guess we could preemptively disable - * buggy libevent modes based on the version _before_ initializing it, - * though, but then there's no good way (afaict) to warn "I would have used - * kqueue, but instead I'm using select." -NM */ - /* XXXX022 revist the above; it is fixable now. */ + /* It would be better to disable known-buggy methods rather than warning + * about them. But the problem is that with older versions of Libevent, + * it's not trivial to get them to change their methods once they're + * initialized... and with newer versions of Libevent, they aren't actually + * broken. But we should revisit this if we ever find a post-1.4 version + * of Libevent where we need to disable a given method. */ if (!strcmp(m, "kqueue")) { if (version < V_OLD(1,1,'b')) buggy = 1;