Hi all, I've following findings: * MUTLITHREADING safety should be a capabilty since it is implementation specific. Also source code portability requires it. * latex format error in line 364 * 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations accessible for the user running the DRMAA-based application." Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible" is a better wording. * ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments). Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate this is made *very* explicit, that one might need request a job category this is not mentioned in the ReservationTemplate. Therefore I propose to add string JobCategory; in the ReservationTemplate in order to be consistent with the multiple slots request approach. The JobCategory in the spec could be renamed to Category if needed. Anyhow it would be good to add multiple category strings - but this is going to be an implementation specific enhancement if needed. Cheers, Daniel
On 22 June 2011 12:37, 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.
* latex format error in line 364
* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations accessible for the user running the DRMAA-based application."
Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible" is a better wording.
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments). Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate this is made *very* explicit, that one might need request a job category this is not mentioned in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request approach. The JobCategory in the spec could be renamed to Category if needed.
this is fine with me, but lets call it ReservationCategory or Category, not JobCategory.
Anyhow it would be good to add multiple category strings - but this is going to be an implementation specific enhancement if needed.
i'm not sure if i understood you correctly but i don't think that any implementation can change this attribute from scalar to vector, as this would brake binary compatibility. We should decide globally if we want the jobCategory to be string or vector of strings.
Cheers,
Daniel -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Cheers, -- Mariusz
Am 22.06.2011 um 13:18 schrieb Mariusz Mamoński:
On 22 June 2011 12:37, 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.
* latex format error in line 364
* 1511: getAllReservations(): "This method returns the list of all DRMS advance reservations accessible for the user running the DRMAA-based application."
Please make clear that "accessible" does not necessarly mean "usable". Maybe "visible" is a better wording.
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments). Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate this is made *very* explicit, that one might need request a job category this is not mentioned in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request approach. The JobCategory in the spec could be renamed to Category if needed.
this is fine with me, but lets call it ReservationCategory or Category, not JobCategory.
I also thought on ReservationCategory but this needs to add it as a different new concept in the spec and also requires new functions (for retrieving all ReservationCategories). Since both (ReservationCategory and JobCategory) are just strings and in Univa Grid Engine for example both categories maps to the same concept (additional resource requests, which are appended). I would rather change "JobCategory" to "Category" as a generic category name for job or reservation requests.
Anyhow it would be good to add multiple category strings - but this is going to be an implementation specific enhancement if needed.
i'm not sure if i understood you correctly but i don't think that any implementation can change this attribute from scalar to vector, as this would brake binary compatibility. We should decide globally if we want the jobCategory to be string or vector of strings.
No, not changing the method itself. I thought about introducing a completely new implementation specific function, which is not aligned to the standard. I think we already discussed adding a vector type but I AFAIR it was rejected because we then have to handle mutually problems like exclusive resource requests. But for simplicity one way would be the make this again transparent for the standard (i.e. how merging of resource requests is done, it up to the DRMAA implementation). Cheers, Daniel
Cheers,
Daniel -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Cheers, -- Mariusz
* ReservationTemplate(): maxSlots is only supportable with PEs (parallel environments). Same for jobs, they need a PE in order to request more than 1 slot. While in the JobTemplate this is made *very* explicit, that one might need request a job category this is not mentioned in the ReservationTemplate. Therefore I propose to add
string JobCategory;
in the ReservationTemplate in order to be consistent with the multiple slots request approach. The JobCategory in the spec could be renamed to Category if needed.
this is fine with me, but lets call it ReservationCategory or Category, not JobCategory.
I also thought on ReservationCategory but this needs to add it as a different new concept in the spec and also requires new functions (for retrieving all ReservationCategories).
Since both (ReservationCategory and JobCategory) are just strings and in Univa Grid Engine for example both categories maps to the same concept (additional resource requests, which are appended). I would rather change "JobCategory" to "Category" as a generic category name for job or reservation requests.
Since this one of the rare events were Mariusz, Daniel and me (a group majority) agrees on something, I will just do it like this. Best regards, Peter.
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. My $0.02, Andre. -- Nothing is ever easy...
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
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@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
participants (4)
-
Andre Merzky -
Daniel Gruber -
Mariusz Mamoński -
Peter Tröger