[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