BIND 10 #327: early work on recursion

[BIND 10 Development]

#327: early work on recursion
---------------------------+------------------------------------------------
      Reporter:  each      |        Owner:  each                 
          Type:  defect    |       Status:  new                  
      Priority:  major     |    Milestone:  y2 12 month milestone
     Component:  recurser  |   Resolution:                       
      Keywords:            |    Sensitive:  0                    
Estimatedhours:  0.0       |        Hours:  0                    
      Billable:  1         |   Totalhours:  0                    
      Internal:  0         |  
---------------------------+------------------------------------------------

Comment(by each):

 Replying to [comment:3 stephen]:
 > Also, are default definitions for the operator() methods in these
 classes needed?  If not (and I guess not as the documentation suggests
 that the classes are supposed to be abstract) and if this method
 overridden by a derived class, just declare the method abstract (along the
 lines of "void operator() const = 0" in the class definition).

 Thank you, that "= 0" was the part I'd forgotten.  I kept getting compiler
 and linker errors, and putting the empty declarations into asio_link.cc
 was the only way I found to make them go away; declaring "void
 operator()() const = 0;" solves the problem much more elegantly.

 > ''Class TCPServer''
 > Should the checkin_callback_ and dns_callback_ object also be
 encapsulated in a boost::shared_ptr, as they must persist across calls to
 the operator() method.

 I'll clarify the comment on this point.  The issue is that we need to use
 pointers for most things because when coroutines fork, the member
 variables in the coroutine class are copied not referenced.  In my first
 attempt, I ended up with an async_receive_from() call copying data into a
 buffer and size variable, then yielding to the next operator() call, which
 tried to read the data from a *different* buffer and size variable.
 Turning those into shared pointers fixes the problem neatly.

 The checkin pointers are pointers (and even if they weren't, they're never
 changed by a coroutine, so copying wouldn't cause problems).  I don't
 think they need to be shared because they're allocated on the stack in
 auth_srv, but they can be if it turns out to be a good idea.

 > Regarding the "fork" call in operator(), I'm not clear how the
 scheduling works, especially if multiple TCPServer children are created.
 Does a child run to completion before the parent?  If not, what happens
 when a second child is created - is the previous object now
 unreferencable?  Some detailed comments are required.

 Noted, I'll add comments about this.  (To answer here, though, the child
 continues from the fork until it either completes or reaches a "yield".
 The parent is enqueued so that it can resume afterward--though if any ASIO
 events had been posted prior to the fork, they would be serviced before
 the parent.)

 > ''Class UDPServer''
 > I didn't find the "yield continue" construct in the "Thinking
 Asynchronously in C++" article.  What does it do?

 Good catch.  I was thinking it would yield to another coroutine, and then
 eventually resume at the top of the for(;;) loop... but now that you point
 it out, I'm not certain when, if ever, it would resume since it's not
 pending on an event--and if it did, it would unnecessarily reinitialize
 data_ and sender_.  I'll fix this.

 > Regardless of the  I think that there should be some significant
 detailed of what the macros do, either in in the code or in an associated
 README file.  (A reference to a web site is insufficient as it may
 disappear at any time in the future.)

 Okay.  Thank you for your comments.

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