BIND 10 #2398: msgq crash

[BIND 10 Development]

#2398: msgq crash
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  vorner
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20121204
  medium                             |            Resolution:
                  Component:  msgq   |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  High   |  Estimated Difficulty:  4
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 Replying to [comment:9 vorner]:
 > Hello
 >
 > There are still few things:
 >  * Would it be worth it unifying `send_prepared_msg` and
 `__process_write`? They seem they share a lot of common code now.

 Yeah the error checking can actually be done in __send_data(), as long as
 it's allowed to return 'an integer or None' (None meaning 'socket seems
 dead. destroyed it'); Updated.

 >  * Is it OK? Couldn't it lead to some kind of starvation of one socket
 (if there was a really hight amount of data being sent, there'd always be
 something to write to the socket and it wouldn't get to the read).
 Arguably, there must be some reads somewhere to have writes, but there
 still can be one socket that is unlucky.

 er, what exactly is 'it'? In general, as long as actual data is sent, and
 since it's not looping locally on EAGAIN-like codes (therefore either
 diminishing the amount of data to send or doing the main loop and hitting
 the reads as well), it should prefer sending as much data as the writers
 accept, and then move on to the readers. But maybe I am completely
 misunderstanding your comment :)

 >  * I don't like the way the running is set to false and then there's
 waiting until the read times out. Shouldn't the poll be waken up somehow?
 Waiting 2 seconds seems like a really long time.

 Doh, I realized last night the timeout isn't necessary at all; we can just
 add a second socket pair to control msgq. Done so (and removed the timeout
 in msgq itself again); now the only timeout that is left is the backup one
 to make sure the test doesn't get stuck for eternity.

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