[svn] commit: r1874 - in /branches/trac179/src/bin/xfrin: ./ TODO xfrin.spec.pre.in

[BIND 10 source code commits]

Author: jinmei
Date: Thu May 20 18:00:47 2010
New Revision: 1874

Log:
sync with trunk

Modified:
    branches/trac179/src/bin/xfrin/   (props changed)
    branches/trac179/src/bin/xfrin/TODO
    branches/trac179/src/bin/xfrin/xfrin.spec.pre.in

Modified: branches/trac179/src/bin/xfrin/TODO
==============================================================================
--- branches/trac179/src/bin/xfrin/TODO (original)
+++ branches/trac179/src/bin/xfrin/TODO Thu May 20 18:00:47 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.

Modified: branches/trac179/src/bin/xfrin/xfrin.spec.pre.in
==============================================================================
--- branches/trac179/src/bin/xfrin/xfrin.spec.pre.in (original)
+++ branches/trac179/src/bin/xfrin/xfrin.spec.pre.in Thu May 20 18:00:47 2010
@@ -1,6 +1,7 @@
 {
   "module_spec": {
     "module_name": "Xfrin",
+    "module_description": "XFR in daemon",
     "config_data": [
       {
         "item_name": "transfers_in",