Clean up a comment-conversation about bad libevent version/method combos

This commit is contained in:
Nick Mathewson
2011-03-25 15:32:45 -04:00
parent 444e46d96d
commit 88bb40d8f8
+6 -11
View File
@@ -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;