[or-cvs] r9284: Implement a control status event for bad libevent version/me (in tor/trunk: . doc src/or)

[nickm at seul.org]

Author: nickm
Date: 2007-01-06 02:34:02 -0500 (Sat, 06 Jan 2007)
New Revision: 9284

Modified:
   tor/trunk/
   tor/trunk/ChangeLog
   tor/trunk/doc/control-spec.txt
   tor/trunk/src/or/config.c
Log:
 r11872 at Kushana:  nickm | 2007-01-06 02:14:12 -0500
 Implement a control status event for bad libevent version/method combos.  Warn that libevent <1.1 with select() is needlessly slow.  Reply to comment.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r11872] on c95137ef-5f19-0410-b913-86e773d04f59

Modified: tor/trunk/ChangeLog
===================================================================
--- tor/trunk/ChangeLog	2007-01-06 06:32:59 UTC (rev 9283)
+++ tor/trunk/ChangeLog	2007-01-06 07:34:02 UTC (rev 9284)
@@ -19,6 +19,9 @@
     - Implement CHECKING_REACHABILITY and REACHABILITY_{SUCCEEDED|FAILED}
       server status events so controllers can learn about Tor's progress in
       deciding whether it's reachable from the outside.
+    - Implement BAD_LIBEVENT general status event so controllers can learn
+      when we have a version/method combination in libevent that needs to
+      be changed.
 
   o Minor features (directory):
     - Authorities do not recommend exits as guards if this would shift
@@ -30,6 +33,8 @@
     - Prevent an (unlikely) bug on 32-bit architectures that could make
       directories send 503s incorrectly when BandwidthBurst plus 2 times
       BandwidthRate was over to 2 GB.
+    - Warn that using select() on any libevent version before 1.1 will be
+      unnecessarily slow (even for select()).
 
 
 Changes in version 0.1.2.5-alpha - 2007-01-06

Modified: tor/trunk/doc/control-spec.txt
===================================================================
--- tor/trunk/doc/control-spec.txt	2007-01-06 06:32:59 UTC (rev 9283)
+++ tor/trunk/doc/control-spec.txt	2007-01-06 07:34:02 UTC (rev 9284)
@@ -1030,6 +1030,17 @@
          a NETWORKSTATUS, we decided we're skewed because we got a
          networkstatus from far in the future.
 
+     BAD_LIBEVENT
+     "METHOD=" libevent method
+     "VERSION=" libevent version
+     "BADNESS=" "BROKEN" / "BUGGY" / "SLOW"
+     "RECOVERED=" "NO" / "YES"
+        Tor knows about bugs in using the configured event method in this
+        version of libevent.  "BROKEN" libevents won't work at all;
+        "BUGGY" libevents might work okay; "SLOW" libevents will work
+        fine, but not quickly.  If "RECOVERED" is YES, Tor managed to
+        switch to a more reliable (but probably slower!) libevent method.
+
   Actions for STATUS_GENERAL severity ERR events can be as follows:
 
      BAD_PROXY

Modified: tor/trunk/src/or/config.c
===================================================================
--- tor/trunk/src/or/config.c	2007-01-06 06:32:59 UTC (rev 9283)
+++ tor/trunk/src/or/config.c	2007-01-06 07:34:02 UTC (rev 9284)
@@ -577,7 +577,8 @@
 typedef enum {
   /* Note: we compare these, so it's important that "old" precede everything,
    * and that "other" come last. */
-  LE_OLD=0, LE_10C, LE_10D, LE_10E, LE_11, LE_11A, LE_11B, LE_12, LE_OTHER
+  LE_OLD=0, LE_10C, LE_10D, LE_10E, LE_11, LE_11A, LE_11B, LE_12, LE_12A,
+  LE_OTHER
 } le_version_t;
 static le_version_t decode_libevent_version(void);
 #if defined(HAVE_EVENT_GET_VERSION) && defined(HAVE_EVENT_GET_METHOD)
@@ -3783,6 +3784,7 @@
   { "1.1a", LE_11A },
   { "1.1b", LE_11B },
   { "1.2",  LE_12 },
+  { "1.2a", LE_12A },
   { NULL, LE_OTHER }
 };
 
@@ -3810,6 +3812,7 @@
   int buggy = 0, iffy = 0, slow = 0;
   le_version_t version;
   const char *v = event_get_version();
+  const char *badness = NULL;
 
   version = decode_libevent_version();
 
@@ -3817,6 +3820,12 @@
    * 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 */
   if (!strcmp(m, "kqueue")) {
     if (version < LE_11B)
       buggy = 1;
@@ -3828,7 +3837,7 @@
       buggy = 1;
     else if (version < LE_11)
       slow = 1;
-  } else if (!strcmp(m, "poll")) {
+  } else if (!strcmp(m, "select")) {
     if (version < LE_11)
       slow = 1;
   } else if (!strcmp(m, "win32")) {
@@ -3840,16 +3849,24 @@
     log(LOG_WARN, LD_GENERAL,
         "There are known bugs in using %s with libevent %s. "
         "Please use the latest version of libevent.", m, v);
+    badness = "BROKEN";
   } else if (iffy) {
     log(LOG_WARN, LD_GENERAL,
         "There are minor bugs in using %s with libevent %s. "
         "You may want to use the latest version of libevent.", m, v);
+    badness = "BUGGY";
   } else if (slow && server) {
     log(LOG_WARN, LD_GENERAL,
         "libevent %s can be very slow with %s. "
         "When running a server, please use the latest version of libevent.",
         v,m);
+    badness = "SLOW";
   }
+  if (badness) {
+    control_event_general_status(LOG_WARN,
+        "BAD_LIBEVENT VERSION=%s METHOD=%s BADNESS=%s RECOVERED=NO",
+                                 v, m, badness);
+  }
 
 }
 #else