[DRMAA-WG] IDL issues
andre at merzky.net
Tue Jun 21 17:05:04 CDT 2011
2011/6/21 Peter Tröger <peter at troeger.eu>:
>> The bigger ones are likely caused by my limited understanding of the
>> background which led to the design, so please bear with me - I don't
>> want to reopen any discussions which have been closed for good...
> I like your attitude ;-) ...
Thanks for the answers, that helps. Some comments inlined below.
>> - I think the following is asymmetric. There is likely a reason,
>> but I am not sure I understand it:
>> - job session: create (name, contact), open (name), close
>> (session), destroy (name)
>> - reserv. session: create (name, contact), open (name), close
>> (session), destroy (name)
>> - monit. session: create ( contact), close
>> From the above, it seems like create/close are pairs? I would
>> naively expect the following
>> pairs: open/close and create/destroy, as usual - what is the
> I don't get your point. Creation returns a new persistent XXXsession
> instance. Open allows you to re-access the persistent existing session.
> Close is for cleanup after both create and open. Destroy throws away the
> persistent information, and therefore does not demand an open session
Why not close(name), so that all ops work with name as arg? Would be
>> Why is the Monitoring session handled differently, i.e. has no
> Monitoring session have no persistency, so they need no name for opening,
> and no destruction.
If something has a create, I would expect it to have a destroy, too.
That might just be me, but semantically those two go together...
Anyway, your explanation helps!
>> - JobWaitStarted/Terminated: The function returns always a Job
>> object, in order to allow chaining,
>> e.g. job.wait(JobStatus.RUNNING).hold(). The session-level functions
>> I find that strange and inconsistent - chaining is not supported
>> elsewhere AFAICS, why here?
>> What is the advantage over 'job.wait(JobStatus.RUNNING);
>> job.hold();'? this has exactly the same race conditions...
> Chaining was raised as important thing only for the wait functions. I am too
> lazy to search the minutes for this, but it is handy in OO languages. We
> didn't spend deeper thoughts on supporting this elsewhere.
You may want to make sure that chaining was *not* introduced to
prevent race conditions - because it does not.
> Proposals welcome.
Proposal: don't do chaining, it makes error handling a nightmare - for
almost all languages really, but in particular so for exception-less
>> - sessionManager.drmaaVersion: this seems to return the
>> implementation version, not the
>> DRMAA spec version (i.e. 2.0). I think this is useless without
>> also reporting the
>> drmaaName, i.e. the implementation name. Otherwise the user may
>> report to you that
>> she is using version 4.5, but what implementation?? ;-)
> You get the DRMS type, this is your DRMAA implementation. I propose that
> there will be no two DRMAA implementations for the same DRM system in the
> same language.
Woah - you MAY be able to ensure that for the current WG constituency,
but you are writing a *standard*! You expect there will only *one*
implementation using fork, for example? Only one implementation for
PBS? You can never ensure this, and that contradicts the idea of an
The potentially missing API call is a minor point really, but your
argument does not hold water ;-)
>> - what is the use of the sessionManager interface? It cannot be
>> created/destroyed, so is likely a singleton?
>> This however is not explicit in the spec. A sessionManager does
>> not seem to have state (apart from the new
>> addition of a monitoring callback), but a stateless singleton is
>> rather useless? All methods can easily be
>> provided as free functions - is a language binding allowed to do that?
> Yes, it's a singleton.
This should be noted in the spec (unless I missed it).
> Yes, you can do free functions in the language
> binding. IDL does not support that.
Nothing is ever easy...
More information about the drmaa-wg