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

[BIND 10 Development]

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

  * owner:  jelte => jinmei


Comment:

 Replying to [comment:16 jinmei]:
 > From a quick look at the implementation of reset() (which I think is in
 asio/detail/xxx_io_service.hpp), reset() actually doesn't trigger an
 exception or otherwise indicate an error even if the assumption isn't met.
 But I'm not so sure if this means this usage is actually safe or it
 actually breaks something fundamental inside io_serivce which could cause
 strange failures in rare cases.
 >
 > One possible workaround would be
 >  - to set session timeout to 0 (meaning no timeout) in b10-auth just
 before starting the main loop, and
 >  - in readData(), skip the reset()->run_one() trick completely, if
 getTimeout() == 0
 >

 No, then we wouldn't have timeouts and we'd be back where we started.
 Unless you are thinking of changing the timeout value for those times we
 need it (i.e. before every call to group_recvmsg(). But I think I have
 found another solution to the original problem; there's a 'work' service
 that simply tells run not to stop. Added this to the applications that do
 not have a continuous work object (like the tests), and reset() is not
 needed anymore. r2750.

 >
 > > >  - I don't understand why we need to check getTimeout() != 0 here:
 > > > {{{
 > > >             if (read_result && getTimeout() != 0) {
 > > > }}}
 > >
 > > If timeout is set to 0, the timer isn't started, and waiting for it to
 end would result in an eternal loop (after data has arrived). Added
 comment.
 > >
 > Hmm, but doesn't timer.cancel() triggers the setResult() event for the
 timer?  Perhaps it's not the case when the timer hasn't started in the
 first place?
 >

 Nope, since we haven't added setResult it to the callbacks of the timeout,
 cancel() would be a nop.

 >  - operator unspecified_bool_type: Operator returns non-null if there is
 a non-success error code.
 >  - operator!: Operator to test if the error represents success.
 >

 Right. You have convinced me, and I updated it in r2752 (with a small
 comment).

 Jelte

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