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:  1.29          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

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


Comment:

 Hello

 Replying to [comment:10 jinmei]:
 > 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.

 It seems OK now.

 > 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.

 OK, then it may have been boost::thread or something. I know we had
 trouble with some of them, but I'm not sure which one.

 I think this can be merged.

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