[svn] commit: r1835 - /trunk/src/bin/xfrin/TODO

[BIND 10 source code commits]

Author: jinmei
Date: Sat May 15 19:14:29 2010
New Revision: 1835

Log:
yet more comments

Modified:
    trunk/src/bin/xfrin/TODO

Modified: trunk/src/bin/xfrin/TODO
==============================================================================
--- trunk/src/bin/xfrin/TODO (original)
+++ trunk/src/bin/xfrin/TODO Sat May 15 19:14:29 2010
@@ -24,3 +24,30 @@
     master closes the connection.
             if self._recv_time_out:
                 raise XfrinException('receive data from socket time out.')
+13. according to the source code xfrin cannot quickly terminate on shutdown
+    if some of the xfr connections stall.  on a related note, the use of
+    threading.Event() is questionable: since no threads wait() on the event,
+    it actually just works as a global flag shared by all threads.
+    this implementation should be refactored so that a shutdown command is
+    propagate to all threads immediately, whether it's via a builtin mechanism
+    of the threading module or not (it's probably "not", see below).
+14. the current use of asyncore seems to be thread unsafe because it
+    relies on a global channel map (which is the implicit default).
+    each thread should probably use its own map:
+      asyncore.dispatcher.__init__(self, map=sock_map)
+      # where sock_map is thread specific and is passed to
+      # XfrinConnection.__init__().
+15. but in the first place, it's not clear why we need asyncore.
+    since each thread is responsible for a single xfr connection,
+    socket operations can safely block (with timeouts).  this should
+    be easily implemented using the bear socket module, and the code
+    would look like more straightforward by avoiding complicated logic
+    for asynchrony.  in fact, that simplicity should be a major
+    advantage with thread over event-driven (the model asyncore
+    implements), so this mixture of two models seems awkward to me.
+16. having said all that, asyncore may still be necessary to address
+    item #13: we'd need an explicit communication channel (e.g. a
+    pipe) between the parent thread and xfr connection thread, through
+    which a shutdown notification would be sent to the child.  With
+    this approach each thread needs to watch at least two channels,
+    and then it would need some asynchronous communication mechanism.