[drmaa-wg] C binding data structures

[Roger Brobst]

Hi Matthieu.

I think it might be useful to think of a drmaa_job_template 
as a table of name-value pairs.  You ~could~ implement this 
table as an array of names and an array of values, where the
value of associated with attr_names[i] would be stored at
attr_values[i].  
Other implementations might be a hashTable or a linked list of:
   struct attr_s {
       struct attr_s *next;
       char          *name;
       char          *value;
   };
(For simplicity, I'm ignoring that there are string-valued
 attributes and stringVector valued attributes)


Since the specification does not indicate an interface to
obtain an array of attribute names associated with a specific
job template, there isn't a particular benefit to implementing
the table as two parallel arrays.
Note, however, that the spec does indicate a
    drmaa_get_attribute_names
interface to obtain the attribute names associated with 
the DRMAA implementation ... this is not on a per-template basis.

You mentioned drmaa_get_next_attr_{name,value} functions ...
I did not locate them in the drmaa C binding document.
The end-user is not
   "condemned to use alternatively get_next_name and get_next_value
    functions to be certain he gets the proper value for the proper
    attribute name?"
The drmaa_get_attribute routine accepts the attribute name and
output the corresponding value from the template.


You are correct that each successful call to 
    drmaa_set_attribute(drmaa_job_template_t *jt,
        const char *name, const char *value,
        char *error_diagnosis, size_t error_diag_len);
would modify an existing table entry, or add a new table entry.


-Roger


In a previous e-mail, Cargnelli, Matthieu wrote:
> Hello,
> 
> Sorry for these questions that will probably look a little dumb, but I 
> just can't figure it out. I hope this is the right place to ask these 
> questions...
> 
> I'm trying to write a DRMAA C binding for Torque/OpenPBS. I've read the 
> drmaa C binding documents and some of this mailing list archive, but 
> couldn't find an answer.
> 
> I was defining a job_template structure containing the necessary 
> strings, something like this:
> struct drmaa_job_template_s
> {
>   char* drmaa_remote_command;
>   char* drmaa_js_state;
>   char* drmaa_wd;
>   [...]
> };
> 
> But eventually I thought that it would rather be something like:
> struct drmaa_job_template_s
> {
>   drmaa_attr_names_t* _attr_names;
>   drmaa_attr_values_t* _attr_values;
>   [...]
> };
> that should be implemented (at least that would justify the opaque 
> string vectors).
> 
> Could someone please shed some light on this matter please?
> I'm really unable to find that information anywhere.
> 
> Besides, what are we supposed to put in the opaque string vectors 
> if the first case apply?
> 
> In both cases how are we supposed to make the relation between the 
> attr_name vector and the attr_value vector? I suppose these actually 
> contain pairs of value. But as they can only be accessed by 
> drmaa_get_next_attr_name and drmaa_get_next_attr_ value functions, is 
> the user condamned to use alternatively get_next_name and get_next_value 
> functions to be certain he gets the proper value for the proper 
> attribute name?
>  
> Finaly, that leads to the function:
> /*
>  * Adds ('name', 'value') pair to list of attributes in job template 'jt'.
>  * Only non-vector attributes may be passed.
>  */
> int drmaa_set_attribute(drmaa_job_template_t *jt, const char *name, 
> const char *value, char *error_diagnosis, size_t error_diag_len);
> 
> If I'm correct, this function would add (or modify) one element to 
> attr_name and one to attr_value string vectors... Or am I totally wrong 
> about it ?
> 
> Sorry for such a bunch of questions.
> 
> Regards
> 
> Matthieu Cargnelli
>