<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Two immediate concerns with my general approach:</div><div> * Log timestamps could be skewed from the time they were emitted.</div><div>    - I am looking at generating the messages sooner, but sending them at a delay.</div><div>    - Potentially, some logging backends might discard in-message timestamps.</div></div></div></span></blockquote><div><br>
                </div><div>The latest patchset now addresses this by wrapping handle(), rather than the error/warning/info/etc methods.</div><div><br></div><div>I've also added a tunable to limit the backlog size. When this queue fills, logging becomes semi-synchronous until it is no longer full. One would set a limit if they want to restrict memory growth. Right now, this defaults to unlimited, but it might make sense to put a reasonable default such as 4,000 messages?</div><div><div><div><br></div><div>Regards,</div><div>Eric Windisch</div></div></div>