BIND 10 #2874: Test the Coroutines/RCU approach for resolver multi-threading

[BIND 10 Development]

#2874: Test the Coroutines/RCU approach for resolver multi-threading
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |  UnAssigned
            Priority:  medium        |                       Status:
           Component:  resolver      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130723
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  7             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => UnAssigned
 * status:  accepted => reviewing


Comment:

 Hello

 It is ready for review. There are probably two things:

 The boost coroutine library is not available on all systems and it needs
 compiled boost (headers-only is not enough). I added some simple check for
 boost, but I'm not sure if it is done properly or when it'll break. I'd
 not like the compilation to break just because of the benchmark, so I'm
 thinking we either need to do the checks properly (but I did not succeed
 in learning how to use autoconf properly, I must have some mental block
 there), or provide an explicit switch to enable the resolver benchmarks ‒
 most people don't want them anyway. Yet another option would be not to
 merge these to master, but to a separate branch, but I don't really like
 that much.

 The other thing, I hope it is not too hard to read. It seems better with
 these coroutines than with the state-less ones, but it is still kind of
 mind-bending to try and follow them through the scheduler (they look OK if
 looked only from inside of the coroutine, so all the complexity is in the
 scheduler).

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