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

[Peter Troeger]

> myself) tend to be obsessively committed to doing things  "the Cocoa
> way": after all, if we wanted to use the C interface  directly, we

Doing it in "the language" way is always fine, but ...

 > I don't really see the need to be IDL-compliant unless there's a  strong
> desire out there for this. I think Cocoa programmers would be  happier

IDL-Spec- (or DRMAA-) compliance simply means that you take care of
offering everything we described as functional and behavioural parts of
DRMAA. Some parts of DRMAA will not sound feasible or useful in your
particular context. This is ok - it's a standard for everybody.

At the end, it always comes back to question why anybody needs a
language-independent spec. From my understanding, these kind of
definitions are useful in order to keep DRMAA semantics in all
languages, regardless of the implementation. It is the task of the
language binding author to ensure that an appropriate mapping takes place.

The DRMAA group so far decided to offer explicit destruction of job
template resources. This is reasoned by the fact the an application
should have a chance to render a particular job template explicitely as
invalid. One example could be a web application using DRMAA, which
stores job template identifiers in the user session information.

The real problem is that the spec does not reflect this intention for
the function. Even worser, drmaa_run_job() so far has no
DRMAA_INVALID_JOB_TEMPLATE as possible error code. Therefore it would
now be ok the implemented deleteJobTemplate() as empty function.

Comments ?

Peter.



> using something that's Cocoa-like than something that maps  perfectly
> onto the C and Java interfaces. I suspect nobody else out  there (except
> hopefully Apple, starting from my work) will be  creating an Objective-C
> DRMAA implementation. As long as Xgrid is  compliant for C and Java,
> that should be good enough, I think.
> 
> --Ed
> 
> On Jun 6, 2006, at 5:26 PM, Daniel Templeton wrote:
> 
>> 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
>>>>>
>>>>
>>>
>>
>