[DRMAA-WG] OGF35 Wrap-Up

[Peter Tröger]

Dear all,

we had a small but productive meeting at OGF35. Beside the further
discussion about OCCI-DRMAA, we analyzed the DRMAAv2 C binding comments
collected so far:

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

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

[Rayson Ho]

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

[Peter Tröger]

Hi Antonio,

I'm a researcher at the Brazilian National Laboratory for Scientific
Computing (LNCC -- http://www.lncc.br), and also the executive
secretary of the Brazilian National System for High-Performance
Computing (SINAPAD -- http://www.lncc.br/sinapad). Very briefly, we
use DRMAA specs in SINAPAD for providing APIs to scientific portals
and we'd be quite interested in the OCCI-DRMAA initiative. I found
some pointers to a draft specification, but I'm not allowed to get to
them, even being registered in GridForge.

As the Redmine project page says, you can clone the repository with the specification document sources:

git clone http://redmine.ogf.org/git/standards/applications-area/drmaa-wg/drmaav2-occi-binding.git

Please note that this is a document under work. Furthermore, the OCCI-DRMAA standardization is currently suspended, since the OCCI guys need to improve at some points first. One example is the currently missing pagination support in OCCI. You find according comments in the TEX file.

Where can I get such draft so to evaluate its ideas' applicability in
the SINAPAD context?

Read the current document, take nothing for granted, and come back with your ideas :)

Beside that, what about DRMAAv2 support in your projects ? Any language bindings you need to have beside C and OCCI ?

Best regards,
Peter.

Thank you in advance for your attention.
Best regards,
--
Antonio Tadeu Azevedo Gomes, DSc.
http://www.lncc.br/~atagomes
http://www.lncc.br/sinapad
http://martin.lncc.br