BIND 10 #2617: MSGQ_RECV_ERR errors on clean shutdown

[BIND 10 Development]

#2617: MSGQ_RECV_ERR errors on clean shutdown
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  msgq          |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  Discuss (4?)  |                 CVSS Scoring:
         Total Hours:  2.11          |              Defect Severity:  Low
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei
 * totalhours:  0 => 2.11


Comment:

 Hello

 Replying to [comment:22 jinmei]:
 > I've tried that for the kqueue version, and found it causing a lettuce
 > test failure.  I've not fully looked into it, but I suspect the test
 > scenario (perhaps implicitly) expect msgq to know one closing socket
 > until operations on all other sockets are completed.  This may not
 > necessarily be a defect of msgq but can be a matter of test setup,
 > but in any event I'd say it's beyond the scope of this ticket (note,
 > again, this branch doesn't introduce a new behavior on this point).
 > Likewise, I'd hold off updating the "poller" version.
 >
 > For now I've added some more comments about the code.  For longer
 > term, I'd suggest we first add more unit tests around the code here so
 > we can be more sure about safety of such changes, then unify the
 > poller/kqueue version to simplify the code (maybe so it'll use select;
 > we don't need scalability here and select is probably most portable),
 > and, on top of that, we can clean up this point.
 >
 > So I propose we close this ticket without changing the behavior on
 > this point.

 OK, that seems reasonable. There's one small typo in the comment (okayb):
 {{{
 # Note: it may be okayb to read data if available
 }}}

 With fixing it, please merge.

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