[DRMAA-WG] meeting minutes March 3rd 2010

[Daniel Gruber]

Am Montag, den 15.03.2010, 17:00 +0100 schrieb Peter Tröger:
> 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. 
> 
> 
> > 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.
> 
> 
> >    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 proposal was just to add information (or an explicit statement) to 
the standard, that it is up to the implementation which fields 
are updated (and if the fields are updated at all). Because, if 
I remember correctly, that polling for information from client 
side to master and master to execution host can create much overhead
(costs) and therefore from some implementation it can be better
(when they have no imformation at master side) to report nothing.

Daniel
 

> 
> Thanks,
> Peter.
> 
> 
> 
> 
> --
>   drmaa-wg mailing list
>   drmaa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/drmaa-wg