BIND 10 #296: Timeouts on msgq's cc-channel

[BIND 10 Development]

#296: Timeouts on msgq's cc-channel
-------------------------------+--------------------------------------------
      Reporter:  jelte         |        Owner:  jelte               
          Type:  enhancement   |       Status:  new                 
      Priority:  major         |    Milestone:  y2 6 month milestone
     Component:  Unclassified  |   Resolution:                      
      Keywords:                |    Sensitive:  0                   
Estimatedhours:  0.0           |        Hours:  0                   
      Billable:  1             |   Totalhours:  0                   
      Internal:  0             |  
-------------------------------+--------------------------------------------

Comment(by jinmei):

 Some random comments:

  - overall it seems to work as intended, but I'd confirm it works even if
 there's another outstanding event and it's completed before this
 async_read() is done.
  - I hope this type of trick is a short term workaround.  I guess we
 should eventually make these asynchronous.
  - if I remember correctly there's a version of async_read where you don't
 have to specify "transfer_at_least".
  - is it okay to ignore other errors than operation_aborted in
 async_read()?  it's also not clear what this code tries to do by
 explicitly excluding operation_aborted.
  - there are some style guide violations.
  - I thought the type of the error_code arg in asio callbacks is const
 asio::error_code&.
  - the policy of whether to use the asio namespace doesn't seem to be
 consistent.  (and I'm not sure why we don't need to add it for
 "async_read"...)
  - this seems to be an incomplete what() message:
 {{{
             isc_throw(SessionTimeout, "Timeout or error on ");
 }}}

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