BIND 10 #624: asiolink test fails on OSX server

[BIND 10 Development]

#624: asiolink test fails on OSX server
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  jinmei
                     Type:  defect   |               Status:  reviewing
                 Priority:  minor    |            Milestone:  R-Team-
                Component:           |  Sprint-20110308
  resolver                           |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  1.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:6 stephen]:

 > io_service::poll() looks in the queue for event handlers and runs the
 ones it finds.  If there are none, it returns immediately.
 io_service::run_one() will run one event handler and return, but if there
 are none in the queue when it is called, it will block until one appears
 >
 > This suggests platform-dependent timing behaviour.  If, for some reason,
 the Mac does not execute the I/Os immediately when poll() is called (or
 the I/O post-processing which puts the handlers in the queue is slow),
 there may be nothing in the queue when poll() is called.

 Hmm, I see.  I still don't understand why we saw this on this
 particular Mac.  I can imagine that if the underlying network stack is
 asynchronous that could happen, but MacOS X should be using
 BSD-derived stack, and shouldn't be different from other BSD systems
 on that point.  Also, this machine shouldn't be that slow (right?), so
 the machine speed doesn't seem to be the reason.

 Another issue comes up with me by reading the above explanation: by
 using run_one(), the test could hang indefinitely if the test code or
 some related tested code has a particular type of bug, which is not
 good.  Ideally we should have a separate (reasonably long to avoid
 false positive) timeout so that we can terminate the test even in such
 a worst case.

 That said, I wouldn't request these be addressed within the context of
 this ticket.  So I'm okay with closing this one, and I'm going to do
 so as you asked.

 > This suggests platform-dependent timing behaviour.  If, for some reason,
 the Mac does not execute the I/Os immediately when poll() is called (or
 the I/O post-processing which puts the handlers in the queue is slow),
 there may be nothing in the queue when poll() is called.

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