BIND 10 #1599: introduce "asiodns::UDPSyncServer"

[BIND 10 Development]

#1599: introduce "asiodns::UDPSyncServer"
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  kevin_tes
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120306
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  7
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => kevin_tes


Comment:

 Hello

 Replying to [comment:8 kevin_tes]:
 > A litter things I take here.
 > {{{
 >     if (ec) {
 >         using namespace asio::error;
 >         if (ec.value() != would_block && ec.value() != try_again &&
 >             ec.value() != interrupted) {
 >             return;
 >         }
 >       // Some kind of interrupt, spurious wakeup, or like that. Just try
 reading
 >       // again.
 >       if (0 == length) {
 >             scheduleRead();
 >             return;
 >       }
 >     }
 > }}}
 > Instead of this one,may be better for performance consider.

 But your version is different ‒ if the error did not happen (eg. `ec` is
 false), but no data was read (`length` is zero), your version tries to
 process it, while mine does not. I'm not sure if this ever happens (maybe
 it could, on a spurious wakeup), but it is copied from the udp_server this
 way, so I expect there was a reason for this.

 And the performance difference should be non-measurably small (if any at
 all, compiler should be able to optimise the check of ec out if it would
 be faster that way) anyway.

 Do you agree on keeping it this way?

 > May be the comments for this method should be changed in order to
 explain why it throws here.

 OK, explanation was added.

 Thank you

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