On 17 Feb 2014, at 00:48, Amos Jeffries <squ...@treenet.co.nz> wrote:
> On 17/02/2014 2:51 a.m., Kinkie wrote:
>> Hi all,
>> I'm working on debug together with Amos, working on reducing the
>> size of the API, removing cruft and making it a bit speedier in the
>> meantime.
>> I'm looking into refactoring ctx_enter/ctx_exit into RAII, but right
>> nw i can't remember ever seeing a context dump in a cache.log.
>> Is it actually used anywhere or is it just something we could get rid
>> of without regret?
>
> It's used to prevent functions or methods used in displaying debugs()
> content from screwing up when recursively calling debugs().
>
> The RefCount and CbcPointer lock display messages are a good example,
> Ip::Address string conversion for printing and similar object self-print
> mechanisms, possibly also SBuf constructor/destructor when a string is
> generated for printing, etc.
>
> You should be able to see Ctx level 1 or so in a full ALL,9 log.
>
> It may also have been intended for the AUFS threads to separate lines
> when overlapping. Though in practice it fails at that and we now use
> thread-local Debug connections and the ostringstream buffering to ensure
> whole per-line writes to cache.log.
but the ctx requires an explicit request by the client (and a fairly obnoxious
one since a ctx_exit needs to be on each code path leading out of the function
where ctx_enter is present.
It is currently only used in HttpStateData::processReplyHeader,
HttpStateData::haveParsedReplyHeaders, MemObject::~MemObject
.
Honestly it sounds to me like something which is not really used and it's a lot
of lines of horrible code, plus it has nothing in there that can't be found in
debugs(), which by the way, as it is coded now is not reentrant: if called
recursively it will lock twice on the same mutex :\
Kinkie
