[K42-discussion] why destory theDeletedObj?
Dilma DaSilva
dilma at watson.ibm.com
Tue Sep 26 14:54:21 EST 2006
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>
More information about the K42-discussion
mailing list