RE: what do we think about this row destroy

[Andy Bierman <abierman@cisco.com>]

At 10:49 AM 11/16/2002 -0800, Dave Thaler wrote:
>> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>> 
>> mplsFTNRowStatus OBJECT-TYPE
>>    SYNTAX              RowStatus
>>    MAX-ACCESS          read-create
>>    STATUS              current
>>    DESCRIPTION
>>        "Used for controlling the creation and deletion of this
>>         row.  All writable objects in this row may be
>>         modified at any time. Setting this variable to
>>         'destroy' when the MIB contains one or more RowPointers
>>         pointing to it results in destruction being
>>         delayed until the row is no longer used."
>>    ::= { mplsFTNEntry 2 }
>> 
>> so a SET to destroy will return a noError. Sofar so good
>> But what about a GET while in delay-destroy mode?
>> 
>> I think a better approach would be to return a inconsistentValue
>> which should hint to the manager that some other table entries
>> in other tables need to be deleted first.
>
>Was there a good reason in this case why a set to destroy shouldn't 
>instead have a side effect of changing/deleting the other
>RowPointer objects?

 From a programmer's perspective: you never ever NULL out a pointer
in use as some side effect.  The code using that pointer only
checks for NULL when the pointer is initially set and not before
every use of the pointer.


>-Dave

Andy