[DRMAA-WG] other IDL issues
Peter Tröger
peter at troeger.eu
Fri Jun 24 01:44:51 CDT 2011
Am 22.06.2011 um 14:19 schrieb Andre Merzky:
> Hi Daniel,
>
>
> On Wed, Jun 22, 2011 at 12:37 PM, Daniel Gruber <dgruber at univa.com> wrote:
>> Hi all,
>>
>> I've following findings:
>>
>> * MUTLITHREADING safety should be a capabilty since it is implementation specific. Also
>> source code portability requires it.
>
> The spec leaves many things to the implementation - I don't think all
> those degrees of freedom should be exposed for inspection, as
> capabilities. That will quickly grow and becom unwieldy. For
> example, optional fdeatures are: struct serialization, fetch info of
> dead jobs, allow job annotations, support non-DRMAA jobs and
> reservations, and many more.
>
> Cabilities should only apply to API level features, IMHO, not to
> implementation details. Those need to go into the documentation of
> the implementation.
I strongly support this argumentation, since it makes the scope of the capability feature very clear. Beside that, any promise about multithreading support (or re-entrancy) is a *lie*. Serious programmers do not promise that, since the only way to be absolutely sure is some very fat global lock. It is a pure implementation detail in the sense that it does not change API semantics.
Best regards,
Peter.
>
> My $0.02, Andre.
>
>
>
> --
> Nothing is ever easy...
> --
> drmaa-wg mailing list
> drmaa-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/drmaa-wg
More information about the drmaa-wg
mailing list