BIND 10 #216: Xfrin: Implement the feature items in TODO file.
BIND 10 Development
do-not-reply at isc.org
Tue Aug 17 09:48:06 UTC 2010
#216: Xfrin: Implement the feature items in TODO file.
------------------------------+---------------------------------------------
Reporter: zhanglikun | Owner: shentingting
Type: enhancement | Status: reviewing
Priority: major | Milestone: y2 6 month milestone
Component: xfrin | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours:
Billable: 1 | Totalhours:
Internal: 0 |
------------------------------+---------------------------------------------
Comment(by shentingting):
Replying to [comment:10 jinmei]:
Now I am thinking about adding test case problem. for
xfrinConnection.send/recv/_loop/close are copied from asyncore library,
and those functions are all called based socket API. so I don`t think it
is necessary to add new test case for those function.
why did we switch from asyncore to select?
There are several reasons:
1. It is not necessary to use 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.
2. we'd need an explicit communication channel (e.g. a socket pair)
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. But the socket pair is not
asyncore.dispatcher type or its subtype, and it is difficult to switch it
into a type that asyncore can listen. So it can not put this socket pair
into map, the notify channel is difficult to build. Select can compelte
the same function as asyncore in xfrin deamon, and can build a new notify
channel to deal with quickly terminate on shutdown command. So I switch
from asyncore to select.
3. The asyncores increases complexity, it is more difficult to read
code.
--
Ticket URL: <http://bind10.isc.org/ticket/216#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list