[drmaa-wg] Re: Java DRMAA: why deleteJobTemplate()

[Daniel Templeton]

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
>>>
>>
>