[squid-dev] [PATCH] TidyPointer removal

[Amos Jeffries]

On 11/07/2016 10:20 a.m., Alex Rousskov wrote:
> On 07/10/2016 02:02 AM, Amos Jeffries wrote:
> 
>> * For the LockingPointer(T*) ctor and resetWithoutLocking() method
>>  the caller is responsible for:
>>  - doing a +1 lock itself, and
>>  - exactly once for *each time either is used*, and
>>  - doing it before the call/use.
>>
>> * For release() the caller is taking on responsibility for exactly 1
>> un-lock operation.
>>
>> * For all other methods and operators the recieving Pointer is
>> responsible for the locking.
> 
> 
>> Please reconsider your code examples in light of those requirements and
>> you should see where the bugs in the examples are confusing you.
> 
> I know the requirements. My examples are purposefully built to contain
> problematic self-reset conditions and illustrate the differences between
> self-reset treatment approaches. Real callers may think they follow all
> the rules, but code complexities can easily hide self-assignment/reset
> from them. My examples are simple enough to clearly expose those
> normally hidden problems.
> 
> It is impossible to study self-reset treatment approaches using
> perfectly correct caller code. Perfectly correct caller code does not
> have self-resets.
> 

So your argument is that people write buggy code sometimes and its
impossible to find 100% of bugs. Therefore we must add a workaround that
hides bugs and actively encourages more buggy code to be written by
turning the actual cases of good code into hard-to-identify memory leaks.

Hell no.

If caller(s) need to use a Pointer that does not unlock its delegated
values. Then they should be using TidyPointer/unique_ptr instead of
abusing the LockingPointer. The entire purpose of LockingPointer is to
ensure the unlocking happens when its stored value goes out of scope
(gets replaced, even with self).

Amos