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 jelte):

 Replying to [comment:2 jinmei]:
 > Some random comments:
 >

 thanks :)

 >  - 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.

 and also block until such is the case?

 >  - I hope this type of trick is a short term workaround.  I guess we
 should eventually make these asynchronous.

 I think it'll require quite a bit of redesign of the msgq interface, as
 well as the way it is used (which i suspect is the reason parts of it now
 do an 'empty' async read followed by a sync read if that one is triggers)

 But yes, we should consider it.

 >  - if I remember correctly there's a version of async_read where you
 don't have to specify "transfer_at_least".

 Oh yes, I think it should also work without that. Removing.

 >  - 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.

 No the 'real' errors aren't handled right now; the operation_aborted is an
 'error' value that is given when cancel() is called, in which case the 'i
 am done' boolean isn't set here. Perhaps we should not use a bool but a
 return code directly.

 >  - 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 ");
 > }}}

 Ack. Fixed these (well, I just put asio:: before the async_read()s)

 r2634

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