BIND 10 #2861: synchronization between auth main thread and datasrc builder

[BIND 10 Development]

#2861: synchronization between auth main thread and datasrc builder
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  b10-auth      |  closed
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130723
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |  complete
         Total Hours:  9.40          |                 CVSS Scoring:
                                     |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * status:  reviewing => closed
 * totalhours:  0 => 9.40
 * resolution:   => complete


Comment:

 Hello

 Replying to [comment:15 pselkirk]:
 > Replying to [comment:14 vorner]:
 > > But, I don't see any optional arguments here.
 >
 > I use "optional" in a loose sense here. 'params' may be null, 'callback'
 may be null. I like to see that level of detail, but documentation varies
 widely across the code base.

 OK, I updated the documentation to mention that.

 > > > It seems that it would be better to throw an exception, which would
 be immediately caught and logged by the catch block. The program would
 still terminate, but with something like
 > >
 > > Would it? Generally, the `stderr` of the program is not shown to
 anybody anyway and throwing and catching it in the same function seems
 like badly masked `goto`, confusing the flow.
 >
 > That's the message I got on a quick hack of the code.

 No, I meant „would it be better?“

 > If you think it would be better to terminate directly, I'll defer to
 you. The thing I don't like to see is a program dumping core, because that
 (to me) is a sign of poor error detection and recovery.

 Well, there's no difference in that between my version and the version you
 proposed. Both terminate by abort(), just the error message is different.


 And, about dumping core. There are cases where dumping core is clearly
 badly handled error conditions, like bad user input or when we run out of
 disk space. I still prefer program that crash when they run out of disk
 space than programs that miss important functionality, but that's a
 different story.

 However, there are cases when dumping core is IMO reasonable. The core is
 meant to help find bugs. A SEGFAULT is an example of these. And I believe
 the current case is more similar to the SEGFAULT than to the out-of-space
 condition. We don't know about any case where the error would happen,
 except for inconsistent internal state. As we don't know what such error
 could mean, there's no reasonable way to handle it. And there is also
 probably a bug somewhere that needs to be found.

 We could hide the core somehow, but that'd be only hypocrisy. We don't
 improve the handling of errors by not showing them to user. We just make
 the situation worse.

 > To trigger the error condition, I just closed the socket. It's
 completely contrived, and I don't know if there's any way to trap the
 `terminate`, so I don't know if there's any practical way to build a test
 case around it.

 Yes, there is. `009e306698d3c8018fc2a83aa2c9cb6bd787a875`.

 > Okay to merge.

 OK, merged. Thanks.

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