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:  0             |              Defect Severity:  Low
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:21 vorner]:

 > > > Yes, I meant this. There's a similar code in the kqueue
 implementation. I don't think there's a reason to it, maybe the original
 author thought the events are exclusive. I don't think anything would
 break if it was changed.
 > >
 > > So are you suggesting to change it in this task?
 >
 > Yes, that would be nice. If there really is reason why this wouldn't
 work, we'll at least know the reason and can add a note into a comment. If
 it works, it will look cleaner.

 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.

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