[DRMAA-WG] Comments on latest DRMAA documents

[Piotr Domagalski]

Hi,

We still have some comments on DRMAA specs:

1. The IDL version says that drmaa_wait(SESSION_ANY) should wait only
on those jobs that were in the session up until the drmaa_wait call.
The latest DRMAA 1.0 spec (June, 2007) doesn't mention it.

I remember quite long discussion [1] where Daniel argued that this
waiting semantics prevents some useful use cases. As I don't see any
clear consensus in that discussion, am I right assuming that the IDL
version has the final agreed semantics?

2. I remember asking questions about DRMAA semantics concerning the
behaviour of drmaa_job_ps on finished (drmaa_wait'ed) jobs [2]. In the
latest DRMAA 1.0 spec, in 3.1.2 it says:

"Succesfull drmaa_wait() and drmaa_synchronize(), with dispose = true
parameter, calls will make job id's invalid by reaping the job run
usage data.".

I think this is the only hint in the spec on what might happen to
drmaa_job_ps on disposed jobs. In [2] Peter suggested adding something
more clear but I can't seen anything like that in current docs. OK, so
I firstly assume that the term "job run usage data" doesn't mean that
only the "rsuage" structure used in drmaa_wait is disposed, but the
whole jobid is from now on considered invalid, so that drmaa_job_ps
returns INVALID_JOB. This term, especially with the next point 3.1.3
talking about "run usage data" with other meaning, is a bit confusing.

But assuming I was right in the previous paragraph, how is one
supposed to implement drmaa_job_ps which supports jobids from other
sessions (or jobs submitted not using DRMAA at all)? When I call
drmaa_wait, it disposes the job, so drmaa_job_ps now returns
INVALID_JOB, but If I ask for the status in another session, it will
return it happily. Is this how it's supposed to work?

[1] http://www.ogf.org/pipermail/drmaa-wg/2006-June/000505.htm
[2] http://www.ogf.org/pipermail/drmaa-wg/2006-May/000453.html

-- 
Piotr Domagalski