BIND 10 #1704: log output mixed

[BIND 10 Development]

#1704: log output mixed
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120529
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  15
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I've not given the branch a full review, but have noticed a few
 possibly substantial points.  So I'd like to discuss them first.

 - should we worry about performance impact of locking and unlocking?

 - As documented, we cannot do complicated things involving resource
   allocation in the `Logger` constructor.  In fact, this branch causes
   crash on my environment due to the static initialization fiasco.
   Not looking into it closely, but we should probably move this stuff
   to `LoggerImpl`.

 - I know it could be tricky, but I'd like to test this feature as much
   as possible.

 - We'll definitely need a changelog entry for this ticket.

 - I'd like to see documentation about the lock file, and the
   relationship with the magic environment variables (including when we
   need to define them).

 - Considering the bind10 process will often start as root and
   initially open the lock file, are others running as a non privileged
   user can get access to it?

 - I'm simply not sure, so just asking: is it a good idea to repeat the
   "unable to use lock file" log when the process fails to open it?

 - I guess a single process can open multiple lock files.  Would that
   cause any problem?

 - Maybe we should allow the bind10 process to delete the lock file at
   the very end of its process?

 - The else block of `Logger::output` is (possibly) not exception
   safe.  Consider the case where the main outputRaw throws.

 - On a related note, isn't there a better primitive than the very low
   level system call?  From a quick look boost also has a similar (in
   addition to interprocess_mutex) API: file_lock.

 - If we want to log the event when locking/unlocking fails, I think
   it should be an ERROR, not a WARN.

 - for log_test.py, may be a matter of taste, but since we'd need to
   run it from Makefile in practice (due to other setups), we could
   just set B10_FROM_SOURCE in the Makefile before running the test
   script.  That way we don't have to auto-generate it from .in.

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