diff options
| -rw-r--r-- | src/common/compat_libevent.c | 26 |
1 files changed, 15 insertions, 11 deletions
diff --git a/src/common/compat_libevent.c b/src/common/compat_libevent.c index d94f615f7..a52178020 100644 --- a/src/common/compat_libevent.c +++ b/src/common/compat_libevent.c @@ -340,17 +340,21 @@ 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 than to simply + warn about them. However, 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. + + If we saw that the version was definitely bad, we could disable all the + methods that were bad for that version. But the issue with that is that + if you've found a libevent before 1.1, you are not at all guaranteed to + have _any_ good method to use. + + As of Libevent 2, we can do better, and have more control over what + methods get used. But the problem here is that there are no versions of + Libevent 2 that have buggy event cores, so there's no point in writing + disable code yet. + */ if (!strcmp(m, "kqueue")) { if (version < V_OLD(1,1,'b')) buggy = 1; |