[DRMAA-WG] OGF35 Wrap-Up

[Rayson Ho]

On Tue, Jun 19, 2012 at 1:19 PM, Peter Tröger <peter at troeger.eu> wrote:
> - We support the proposal by Daniel to introduce an overall drmaa2_string
> type, instead of using the native char* in the binding. The intended
> semantic is to use drmaa2_string whenever the application is supposed to
> clean up such variable. This can be done by calling drmaa2_string_free() or
> the free function of the surrounding structure (e.g. with job templates),
> depending on the context. This freeing demand must be  documented in the
> spec. It should further be clarified that drmaa2_string_list will return
> drmaa2_string items in the get() operation.
>
> - The pointer-nullification-on-free issue, which would lead to a complete
> shift to double-indirected pointer parameters, has to be decided in a
> voting.

So what does the new interface look like??

I was not very clear before - if we were to take the address of the
pointer and pass it to the free routine, then we should also take the
address of the pointer and pass it into the routine that creates the
object.

I don't think there is an API that requires the software developer to
pass in different types for the allocation & de-allocation.

Traditional C has malloc() & free(), the programmer gets a pointer &
frees the object using the same pointer. In C++, new & delete is the
same.

Even the example that Daniel used also has a matching allocate & free interface.

Since Daniel's original goal is to NULLify the pointer, we may as well
require the programmer to take the address of the pointer when the
list gets allocated.

IMO, it is ugly to get a pointer when you allocate the object from the
system, but then pass in the address of the pointer when you free it.

Rayson





>
> - We agree to the proposal of Stephan Klauck for introducing additional
> interface handle free functions. This leads to a rejection of the "_h"
> suffix proposal.
>
> - There was no clear consensus about the MACOSX issue raised by Rayson Ho,
> so this must be decided in the voting procedure. We obviousely agreed to the
> TRU64 issue also raised by him. Both things will change the root spec.
>
> - We agree to the 64bit processor architecture issue raised by Rayson. The
> current proposal is to add 64Bit variations for all identified ISAs. A
> voting is needed on the latter idea. This will again change the root spec.
>
> - We support the proposal by Stephan Klauck to have an UNSET definition for
> JobInfo instance.
>
> - We support the idea of Rayson Ho to rename DATA_SEG_SIZE to DATA_SIZE.
> This will change the root spec.
>
> - We agree to the comment from Stephan Klauck that the Job::wait...
> functions should return void. This will change the root spec.
>
> The list of resulting open root spec issues (there are more) was approved by
> the participating group members. We further agreed on submitting the root
> specification errata and the finalized C binding spec together after the end
> of the public comment period. Meanwhile, please check the root specification
> issues here:
>
> http://redmine.ogf.org/projects/drmaav2-root-spec/issues
>
> Best regards,
> Peter.
>
> P.S.: If you want to know details about the OCCI-DRMAA progress, just let me
> know.
>
>
> --
>  drmaa-wg mailing list
>  drmaa-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/drmaa-wg