[K42-discussion] why destory theDeletedObj?

[Patrick Bozeman]

Thanks.   That makes sense.  I actually misread the snippet  and kept  
reading that second line as "f = (FSFile *)theDeletedObject", but the  
rest of the info as why he is assigning from theDeletedObj is helpful.

FWIW, I've exercised the volatile dir validation code a few times in  
such a away that fileInfo does get destroyed later and the warning  
message about deleting the theDeletedObj is printed.  I'll check into  
how this was triggered tomorrow.

On Sep 25, 2006, at 9:54 PM, Dilma DaSilva wrote:

>
> Hi Patrick,
>
> I'm not the originator of the manipulation of theDeletedObj below,
> but I think I understand enough to discuss it and point out some
> dangers in this style of programming.
>
> The idea in this piece of code is to replace the object "fileInfo"
> (which we want to destroy) as soon as possible by a generic object
> that has been designed to return an error code when any of its
> virtual methods are invoked. So:
> (1) we make sure we keep the reference for the original object  
> around with
>   FSFile* f = fileInfo;
> (2) replace the original object with an object that has been created
> earlier, that will simply return an error code on any use:
>      fileInfo = (FSFile*)theDeletedObj;
> From now on, if some call in-flight uses the field fileInfo,
> the call will return an error
> (3) destroy the FSFile object fileInfo:
>>     f->destroy();
>
> This idea of having a valid, well-known, pre-constructed object
> "TheDeletedObj" that replies with the proper error code to any
> method invocation comes from Tornado. In K42, we had the intention
> to have a proper TheDeletedObj, but what the clustered object
> infra-structure offers now (theDeletedObj) is not a full solution.
> More importantly, the piece of code that we're discussing here
> DOES NOT involve a clustered object, i.e, FSFIle doesn't not inherit
> from Obj. The developper who added this code (Michal, I believe)
> chose to take advantage of the pre-fabricated theDeletedObj.
> There is one problem with this though: in order for this idea
> of a pre-fabricated object to work, every method in the object
> has to be virtual (so that method dispatching goes go through
> the vtable). Unfortunately, this is not the case for FSFile:
> it has non-virtual methods, and if those methods were invoked
> on theDeletedObj we could be thrashing the system. I'm going
> to address this for now by removing the non-virtual methods of
> FSFile, because they're not in use anymore.
>
> I hope this explanation didn't get people even more
> confused :)
>
> dilma
>
>  Patrick Bozeman writes:
>> Can someone explain the purpose of destroying the theDeletedObj in  
>> the
>> following snippet?
>>
>> SysStatus
>> DirLinuxFSVolatile::eliminateStaleDir(
>>     DirLinuxFSVolatileRef lockedParent /* = NULL */)
>> {
>>     // FIXME: we are not freeing the subtree properly!
>>
>>     FSFile* f = fileInfo;
>>     fileInfo = (FSFile*)theDeletedObj;
>>     f->destroy();
>>
>>     <snip>
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion