[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor/maint-0.2.2] Clean up a comment-conversation about bad libevent version/method combos
commit 88bb40d8f87077e2f954b6de779ac52c637c69ec
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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;
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits