On 3/15/10 9:00 AM, Peter Tröger wrote:

Hi,

2. JobStates
-> Merging suspended state to one state and have optional sub-states
   like for hold state

Changes applied to Wiki document.

4. Thread safety: Taking out the deleteJobTemplate() (implementation
   will delete it automatically, something like garbage collection when
   not referenced anymore)?

We had that discussion 4 years ago, see for example here:

http://www.ogf.org/pipermail/drmaa-wg/2006-June/thread.html

Personally, I would love to throw away all create..() and delete..() functions for data structures. Until now we left them in, because finalizers are no good replacement if you need predictable cleanup code in the library.

Meanwhile, the question is if any DRMAA C implementation actually has such code. For Condor, the answer is no, "create_job_template" and "destroy_job_template" are only used for the bookkeeping:

http://condor-ext.cvs.sourceforge.net/viewvc/condor-ext/condor_src/drmaa/auxDrmaa.c?view=markup

What about SGE and GridWay ? Do you guys have any relevant logic in "create_job_template" and "destroy_job_template" ??

The second argument in the past was explicit resource management for the application itself. This does not hold for anything but C.

In sum: I can live with having these functions only as optional addition in the C language binding, similar to the attribute setter and getter functions. This would mean that they are no mandatory part of the IDL spec.

The SGE implementation does instead have logic in the create and delete. Basically the create mallocs a data structure, and the delete frees it. I thought we had decided, though, that the job templates would be scoped to the session, so to explicitly delete the job templates, terminate the session. We also said that we have to allow an implementation to free job templates without warning if needed. If the client tries to use a freed template, it gets an error.

5. Move JobInfo into Job template. Roger, Dan, Daniel agreed in not to
merge.
(One reason was: Job object is alive and JobInfo information is static)

'Static' somehow implies that JobInfo is only available in some terminal job state. This was the case in DRMAAv1, but now, we wanted to support also monitoring of running jobs. In this case, JobInfo also becomes alive.

Static means that the data is packed into an object that then no longer changes. Let me demonstrate with an example. Assume there are two attributes. If the attributes were merged into the JobTemplate object, then code that gets the value of the first attribute followed by getting the value of the second attribute, they might not both represent the same state. If the attributes remain in the JobInfo object, and the JobInfo object is static, then the attributes all represent the same state. To update them to the current state, the client has to get a new JobInfo object. Make sense?

Explicit statement for DRMS that don't have information from master.
Up to
the implementation which fields are reported.

I don't really understand this part.

The point was just that an implementation should be allowed to not support all monitoring attributes.

Daniel

Thanks,

Peter.


--
  drmaa-wg mailing list
  drmaa-wg@ogf.org
  http://www.ogf.org/mailman/listinfo/drmaa-wg