[DRMAA-WG] IDL issues
Daniel Gruber
dgruber at univa.com
Wed Jun 22 02:31:07 CDT 2011
see inline
Cheers,
Daniel
Am 22.06.2011 um 00:05 schrieb Andre Merzky:
> 2011/6/21 Peter Tröger <peter at troeger.eu>:
>> Hi,
...
>>
>
>>> - 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
>>> (session)
>>>
>>> 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
>>> rationale?
>>
>> 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
>> instance.
>
> Why not close(name), so that all ops work with name as arg? Would be
> more symmetric.
Yeah, but you make explicit that only with a valid handle (i.e. with an
previously opened/created session) you are able to close it. The operation
itself works on a (existing) session not on a string.
My question is: In a OO language binding, wouldn't it be more natural
to have this operation part of the Session itself? JobSesssion xy ... = ...
JobSession.close()? Wouldn't the IDL spec now allow this (it should)?
In case of a close("name") it definitely would not be possible.
Like Peter said destroying works on the name not on an existing session.
This could speed up session cleaning in some cases.
>
>
>>> Why is the Monitoring session handled differently, i.e. has no
>>> name/open/destroy?
>>
>> 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!
It is a runtime object, IMHO even a singleton.
>
>
>>> - 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
> languages.
>
>
>>> - 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
> standard, really...
>
> The potentially missing API call is a minor point really, but your
> argument does not hold water ;-)
I would be fine with adding drmaaName, where implementors can add
their vendor/organization name inside. Just for the case if...
>
>
>>> - 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.
>
> Ok, thanks.
>
>
> Cheers, Andre.
>
>
> --
> Nothing is ever easy...
> --
> drmaa-wg mailing list
> drmaa-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/drmaa-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20110622/5d7bf21c/attachment-0001.html
More information about the drmaa-wg
mailing list