[or-cvs] reenable the part of the code that tries to flush as soon a...

arma at seul.org arma at seul.org
Wed Jun 8 04:55:08 UTC 2005


Update of /home2/or/cvsroot/tor/src/or
In directory moria:/home/arma/work/onion/cvs/tor/src/or

Modified Files:
	connection.c connection_or.c main.c 
Log Message:
reenable the part of the code that tries to flush as soon as an OR outbuf
has a full tls record available. perhaps this will make OR outbufs not grow
as huge except in rare cases, thus saving lots of cpu time plus memory.


Index: connection.c
===================================================================
RCS file: /home2/or/cvsroot/tor/src/or/connection.c,v
retrieving revision 1.373
retrieving revision 1.374
diff -u -d -r1.373 -r1.374
--- connection.c	23 May 2005 05:20:52 -0000	1.373
+++ connection.c	8 Jun 2005 04:55:06 -0000	1.374
@@ -975,6 +975,9 @@
 int connection_handle_read(connection_t *conn) {
   int max_to_read=-1, try_to_read;
 
+  if (conn->marked_for_close)
+    return 0; /* do nothing */
+
   conn->timestamp_lastread = time(NULL);
 
   switch (conn->type) {
@@ -1176,6 +1179,9 @@
 
   tor_assert(!connection_is_listener(conn));
 
+  if (conn->marked_for_close)
+    return 0; /* do nothing */
+
   conn->timestamp_lastwritten = now;
 
   /* Sometimes, "writable" means "connected". */

Index: connection_or.c
===================================================================
RCS file: /home2/or/cvsroot/tor/src/or/connection_or.c,v
retrieving revision 1.174
retrieving revision 1.175
diff -u -d -r1.174 -r1.175
--- connection_or.c	20 May 2005 08:51:45 -0000	1.174
+++ connection_or.c	8 Jun 2005 04:55:06 -0000	1.175
@@ -579,20 +579,26 @@
 
   connection_write_to_buf(n, CELL_NETWORK_SIZE, conn);
 
-#if 0 /* commented out -- can we get away with not doing this,
-       * because we're already round-robining in handle_read?
-       */
 #define MIN_TLS_FLUSHLEN 15872
 /* openssl tls record size is 16383, this is close. The goal here is to
  * push data out as soon as we know there's enough for a tls record, so
  * during periods of high load we won't read the entire megabyte from
- * input before pushing any data out. */
+ * input before pushing any data out. It also has the feature of not
+ * growing huge outbufs unless something is slow. */
   if (conn->outbuf_flushlen-CELL_NETWORK_SIZE < MIN_TLS_FLUSHLEN &&
       conn->outbuf_flushlen >= MIN_TLS_FLUSHLEN) {
     int extra = conn->outbuf_flushlen - MIN_TLS_FLUSHLEN;
     conn->outbuf_flushlen = MIN_TLS_FLUSHLEN;
     if (connection_handle_write(conn) < 0) {
-      log_fn(LOG_WARN,"flushing failed.");
+      if (!conn->marked_for_close) {
+        /* this connection is broken. remove it. */
+        log_fn(LOG_WARN,"Bug: unhandled error on write for OR conn (fd %d); removing",
+               conn->s);
+        tor_fragile_assert();
+        conn->has_sent_end = 1; /* otherwise we cry wolf about duplicate close */
+        /* XXX do we need a close-immediate here, so we don't try to flush? */
+        connection_mark_for_close(conn);
+      }
       return;
     }
     if (extra) {
@@ -600,8 +606,6 @@
       connection_start_writing(conn);
     }
   }
-#endif
-
 }
 
 /** Process cells from <b>conn</b>'s inbuf.

Index: main.c
===================================================================
RCS file: /home2/or/cvsroot/tor/src/or/main.c,v
retrieving revision 1.510
retrieving revision 1.511
diff -u -d -r1.510 -r1.511
--- main.c	7 Jun 2005 18:16:14 -0000	1.510
+++ main.c	8 Jun 2005 04:55:06 -0000	1.511
@@ -344,8 +344,6 @@
 conn_read_callback(int fd, short event, void *_conn)
 {
   connection_t *conn = _conn;
-  if (conn->marked_for_close)
-    return;
 
   log_fn(LOG_DEBUG,"socket %d wants to read.",conn->s);
 
@@ -376,8 +374,6 @@
   connection_t *conn = _conn;
 
   log_fn(LOG_DEBUG,"socket %d wants to write.",conn->s);
-  if (conn->marked_for_close)
-    return;
 
   assert_connection_ok(conn, time(NULL));
 



More information about the tor-commits mailing list