tree b9a67569f81ef378c3c8380ce48ca9e9c774fd68
parent efe9defc65b2b0c9f6cf3b329dc161190f8efcf9
author Tom Cherry <tomcherry@google.com> 1587153911 -0700
committer Tom Cherry <tomcherry@google.com> 1587685091 -0700

base: reimagine line splitting in logger.cpp

Previously, we would split messages by line and call the logger
function for each line.  We would hold a lock during this, to ensure
that multiple threads would not interleave their messages.

There are a few problems with this approach:
1) Using a lock is not efficient and is not fork safe
2) With APEX, there is one lock per instance of libbase, so we must
   move the lock to a location where all instances can access it, or
   perform the line splitting in a way that does not require the lock.

To solve these issues, we reimagine line splitting.
1) We move the lock out of the LogMessage::~LogMessage() and make it
   the logger's responsibility to split lines, giving the logger the
   option to lock or not.
2) We do not need any locks at all for StderrLogger.
   Instead, we generate a single string that contains all of the lines
   with their appropriate log header.  A single write() call is used
   to output this at once.
3) Logd handles log messages with newlines correctly, however it only
   accepts up to a maximum size of log message.  Therefore we
   separate the incoming log message into chunks, delimited by new
   lines, up to that maximum size, and send each of those to logd.
   Note that this is the strategy used in
   android.util.Log.printlns().
   This should solve a majority of use cases, since the maximum size
   that logd accepts is nearly 4K, while remaining lock free.
   If interleaving messages absolutely must be avoided, a lock can
   still be used given 1) above.

Bug: 65062446
Bug: 153824050
Test: logging, particularly multi-line stack traces, show correctly
Test: existing and new unit tests
Change-Id: Id0cb5669bee7f912da1e17f7010f0ee4c93be1e3