Am 22.06.2011 um 14:19 schrieb Andre Merzky:
Hi Daniel,
On Wed, Jun 22, 2011 at 12:37 PM, Daniel Gruber <dgruber@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@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg