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

[BIND 10 Development]

#2804: Make sure the ModuleCCSession::groupRecvMsg in blocking mode works even
when already started.
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  Inter-module  |  Tasks
  communication                      |                   Resolution:
            Keywords:                |                 CVSS Scoring:
           Sensitive:  0             |              Defect Severity:  N/A
         Sub-Project:  Core          |  Feature Depending on Ticket:
Estimated Difficulty:  0             |          Add Hours to Ticket:  0
         Total Hours:  0             |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by vorner):

 Well, the thing would need a complete rewrite, but as with anything, I
 guess we don't have time.

 This should make the sync & async reads work quite intuitively, I think
 (but I can't be sure with that code, to be honest).

 The issue is, when the session is started, we schedule a read of size 0.
 This calls a callback whenever there are data on the session. So, when
 this comes, we schedule one read to read the length and another to read
 the actual message.

 However, if another request to read comes, it schedules _another_ read of
 size 0. So, first the old 0 read callback is called and it schedules one
 read of length 4 bytes. Then the second 0 read is called, scheduling
 another read of length 4. Then the first 4-byte read is done, reading the
 length of message and schedules read for that many bytes. But then, the
 another 4-byte read happens, stealing 4 bytes of the message and wrongly
 interpreting it as length, scheduling some incredibly large read and it
 completely confuses things.

 My idea was, when we do a sync read, we should cancel the original
 0-length read, so it won't fight. After the message is read and returned,
 we restore the 0-length read. Of course, only in case it was scheduled
 originally.

 Async reads are working well (AFAIK), because they only leave a note to
 the top-level loop. Once it reads some message, it checks if it is wanted
 and if so, it calls the callback. If not, it tries if it is a command or
 configuration update. If so, it is handled. If not, the message is either
 stored for future use (in case it is reply) or thrown away (if it is
 command). Or, I observed that much from the code, there's not much
 documentation, so I might be wrong.

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