Ed, I think I had the same conversation with Peter about the .Net implementation. Because of the Java binding, the deleteJobTemplate() method also made it into the IDL spec. Peter's goal with the IDL spec was to be able to effectively generate the other binding specs by applying different mappings to the IDL spec. If you leave out the delete method, your binding won't be IDL-compliant. Of course, since you're not writing a binding spec for it, that shouldn't matter. Peter, care to add anything? Should we revisit this discussion? Daniel Ed Baskerville wrote:
OK, I buy that. Since Cocoa uses a manual retain/release/refcount system for memory management, it should be fine to leave out "delete" in the native Objective-C XgridDRMAA implementation and put it in the dealloc method (the Cocoa equivalent of a finalizer). In C and Java, then, the job-template creation method will alloc/init a new ObjC object (giving it a refcount of 1); and delete will release it (decrementing its refcount to 0 and calling dealloc).
--Ed
On Jun 5, 2006, at 5:26 PM, Daniel Templeton wrote:
Ed,
I hear ya. I struggled with that decision. I agree that logically, a finalizer (the Java term for destructor) makes a lot of sense, especially since some (many? most?) implementations won't even worry about doing any explicit clean-up. My reasoning hinged on two important points: 1) the initial (and still current) SGE implementation did require clean-up, and 2) finalizers are generally a bad idea. Finalizers in Java screw up garbage collection because they end up taking two or more gc's before they actually get collected. (The first gc calls the finalize() method, and assuming finalize() didn't make matters worse, the next gc actually collects the object.) Because the DRMAA specs tend towards inclusivity, the fact that the operation is in the DRMAA 1.0 spec and the SGE implementation would need, is enough to require it in the spec.
(Another issue that has come up since the spec was initially written is how to do a remotable Session interface to a DRMAA library with native code. It that case, it becomes quite a bit easier to simply know that your clients will tell you explicitly when they're done with their job templates.)
In the case of a pure Java implementation with no funny tricks, the deleteJobTemplate() method ends up being essentially empty. I hold that it is within the rights of such an implementation to provide a deleteJobTemplate() method, but to declare the use of the method unnecessary. Such a statement would, of course, carry the caveat of producing code that is not strictly portable, much like the optional and implementation-defined job template properties.
Daniel
Ed Baskerville wrote:
Hi again,
I'm putting together headers for the Xgrid Objective-C DRMAA interface, and ran into another question for you on Java DRMAA: why do you include a deleteJobTemplate method in the Session interface? As far as I can tell, a JobTemplate is basically just a data structure, so why can't releasing the C struct just get taken care of in the destructor?
My instinct with ObjC is to just put it in the analogous "dealloc" method rather than having an explicit deleteJobTemplate: method in DRMAASession. (In my case, there's not even any C struct to free, since Objective-C is the native implementation for XgridDRMAA.)
--Ed