bug #162
implementation specific structs should be visible in drmaa2.h
| Status: | closed | Start date: | 08/26/2014 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Daniel Gruber | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - |
Description
Following finding from Go language binding which
is implemented on top of DRMAA2 C API:
It was required to allocate and free memory of
declared structs which are implementation specific,
like drmaa2_j_s, drmaa2_jarray_s, drmaa2_jsession_s, ...
Hence I moved the typedef from the private header
into the public drmaa2.h so that the language binding
can work with it.
For language binding compatibility reasons we could make
a note to do this in other implementations as well.
History
Updated by Peter Tröger about 8 years ago
- Status changed from submitted to accepted
The OGF-42 meeting decided that this issue is solved by the explicit definition of an implementation-specific DRMAAv2 header file, without declaring the content. This saves us from having differing drmaa2.h header files, as with the original proposal.
The C language binding should define the file name (e.g. drmaa2_impl.h) for that private header. By this, higher-level libraries (e.g. the DRMAAv2 Go library) have a portable way to include the according structure definitions. One example use case is when the Go binding implementation tries to return a job template object that contains a Go Job object. The information for the content of this object comes from the underlying DRMAAv2 C library.
The whole issue is not relevant for applications using the DRMAAv2 C library direcly, since the forward-declared data structures are only returned to them.
Updated by Peter Tröger about 8 years ago
- Status changed from accepted to final review
Updated by Peter Tröger over 7 years ago
- Status changed from final review to closed
Fixed in July 2015 errata.
Updated by Daniel Gruber over 7 years ago
- Assignee set to Daniel Gruber
The approach of drmaa2_impl.h we agreed at ISC 2015 f2f meeting does
not work since those data structures are depended from drmaa2.h.
Hence you would have circular dependencies. Resolving it to have
more header file is not an option.
So we agreed that having the implementation specific functions in the
drmaa2.h file.
(Other formats not available in this archive.