BIND 10 #2804: Make sure the ModuleCCSession::groupRecvMsg in blocking mode works even when already started.

BIND 10 Development do-not-reply at isc.org
Fri Feb 22 10:36:42 UTC 2013


#2804: Make sure the ModuleCCSession::groupRecvMsg in blocking mode works even
when already started.
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  vorner                             |                Status:  new
                       Type:  task   |             Milestone:  New Tasks
                   Priority:         |              Keywords:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  Core
  Inter-module communication         |  Estimated Difficulty:  0
               CVSS Scoring:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 When the session is started, an asynchronous read of size 0 is scheduled,
 to notify when some data come. After that, it checks for incoming command.

 However, if groupRecvMsg is called after this, it also schedules an
 asynchronous read (and starts waiting for the read to finish). The two
 reads then get intermingled and confuse things, losing messages or
 crashing. We need to solve this, because the session is unusable for
 rpcCall (see #2768). Currently, auth keeps a second (plain) session, but
 that is ugly and the plain session doesn't have the rpcCall.

 I tried registering an asynchronous read (by groupRecvMsgAsync) and
 waiting for it to finish in the blocking method, but it didn't work. I'd
 propose another solution. Cancel the asynchronous read of size 0 at the
 start of groupRecvMsg (if it was already started) and return it back after
 the groupRecvMsg ends.

 After that, the rpcCall should be usable by auth, so the attached patch
 could be applied.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2804>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list