[DRMAA-WG] other IDL issues

[Daniel Gruber]

You are both right! Let's close "MULTITHREADING safety should be a capability"

Daniel

Am 24.06.2011 um 08:44 schrieb Peter Tröger:

> 
> 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
>