BIND 10 #2899: move interprocess_sync under lib/log or make it a separate private lib

[BIND 10 Development]

#2899: move interprocess_sync under lib/log or make it a separate private lib
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  build system  |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130514
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Thanks for the review.

 Replying to [comment:9 vorner]:

 > I couldn't run the tests, since it seems to be based on broken master
 (for some reason, I get a bunch of failures from statistics tests). Even
 merging with today's master doesn't help. I believe we should confirm
 distcheck before merging this, as it creates new library and that's often
 source of problems.

 I believe trac2823-regression (in review queue) should fix it.  To
 avoid misleading build/test results, I've created a new branch
 trac2899-2, first merging trac2823-regression and then the original
 trac2899.  Please refer to trac2899-2 (trac2899 has been removed from
 the public repo).

 I'll merge this branch once both this ticket and trac2823-regression
 are ready.

 > Also, with this text, isn't the reason why we don't use the boost
 interprocess that it didn't work on some of our systems? Or it needed
 compiled boost libraries?

 At least these shouldn't be the reason; boost::interprocess::file_lock
 doesn't require a binary library, and while managed_mapped_file didn't
 compile on sunstudio, I don't think file_lock had that problem.  I
 actually don't know why we ended up the in-house version.  I suspect
 it's a kind of NIH syndrome.  In any case, it's true logging is the
 only user, and I believe it's safer to keep its subroutine unless we
 have a real strong reason for not using existing tools for general
 purpose of interprocess synchronization.

 > And, should it use isc::log::interprocess instead of isc::log::internal?
 I generally expect the library name and directory name and the namespace
 match (with some mapping of lower/upper case, dashes and such).

 Hmm, I wanted to make sure it's not intended to be for public use by
 naming it "internal", but I see the consistency point.  Hopefully it's
 sufficiently hidden already, so I've renamed the namespace as you
 suggested.

 > As for the length because of file moves, I discovered that the `-M`
 switch of `git diff` is quite useful.

 Ah, I think I once heard of it but forgot it.  It looks convenient
 indeed.  Thanks.

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