summaryrefslogtreecommitdiff
path: root/libutils/Unicode.cpp
diff options
context:
space:
mode:
authorJintao Zhu <zhujtcsieee@gmail.com>2018-12-20 23:10:41 +0800
committerJintao Zhu <zhujtcsieee@gmail.com>2018-12-20 23:35:54 +0800
commitd3987a96241d211351b0c8b942c047fc16b659da (patch)
treee8738e5f1c26e7b466f495d8cabaac3aa49f4b1f /libutils/Unicode.cpp
parentb81bc9ec007c22db0c3ac8039c050936ca20a028 (diff)
logd: improve logd prune
upon memory usage high(>log_buffer_size), logd will try to prune(erase) all those old log elements which have been read by all readers for reclaiming the memory. As such, a too slow reader will be a hinder to the success of the prune. Logd has to try to kick-out the slow-est reader when memory usage is really too high(>2 * log_buffer_size). But the kick-out operation is just a request to the reader and at what time the reader will exit is always uncertain, beyond control. Furthermore, if you kick-out reader-A, waiting for A to exit; then, another reader-B may come in; then A exit; and then you kick-out-B, waiting for B to exit; and then, ...loop for ever: yes, logd may find that there seems to be always a slow reader hinder its pruning. As we all know, that, logd will probably kick-out a slow reader(logcat), hence, indeed, almost all log capturing tools will try to re-connect logd immediately after it being kick-out-ed. Such retry makes the issue easy to happen. And, we observed that the reader thread may often be blocked by socket write operation, which hindering its exiting and hereby hindering the prune progress. We need gracefully shutdown socket to relieve it from blocking and eventually stop such disaster from happening. Test: monkey test for one day and one night Change-Id: I5496ff74168b71e261914b91c145aa44814a5def
Diffstat (limited to 'libutils/Unicode.cpp')
0 files changed, 0 insertions, 0 deletions